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About This Manual 



Purpose 

This manual explains how to use the Binder compiler to insert a module from a 
separately compiled program into another separately compiled program. 

Scope 

This manual begins with an introduction to the process of binding. The main text 
includes information, syntax, and examples for binding programs and libraries 
written in the same language and in a variety of different languages. 

Audience 

Programmers of all experience levels can use this manual. 

Prerequisites 

You must be familiar with the languages in which the programs you are binding 
are written. 

How to Use Tills Manual 

Read the first section of this manual to understand the binding function and 
process. You can use the rest of the manual as a reference tool to obtain more 
information for your specific program binding needs. 

If you find terms that are unfamiliar to you, refer to the Glossary at the end of 
this manual. 

For a list of A Series documents that discuss programming languages and 
operations related to binding, see the Bibliography at the end of this manual. 

In this document, A Series manuals are referenced by their shortened title. For 
the complete title, see the Bibliography at the end of this manual. 

The syntax of Binder statements is presented in this manual in railroad syntax 
diagram form. If you are unfamiliar with this notation, see Appendix C for a 
complete explanation. 
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Organization 

This manual consists of eight sections, three appendixes, a glossary, a 
bibliography, and an index. The content of the sections and appendixes is 
described as follows: 

Section 1. Understanding the Binding Process 

This section explains the overall binding process. 

Section 2. Binder Language Constructs 

This section describes the elements that form the most primitive structures of the 
Binder language. 

Section 3. Binder Statements 

This section provides the syntax and function of the language elements used with 
Binder. 

Section 4. Binding Programs Written in the Same Language 

This section describes the procedures and techniques required to perform 
intralanguage binding, which is the process of binding programs written in the 
same language. 

Section 5. Binding Programs Written in Different Languages 

This section describes the procedures and techniques required to perform 
interlanguage binding, which is the process of binding programs written in 
different languages. 

Section 6. Binding Intrinsics 

This section describes the binding procedures that are required to create and bind 
intrinsic files. 

Section 7. Binding Programs That Access Databases 

This section explains how to bind programs that access SIM or DMSII databases. 
Section 8. Printing Binding Information 

This section describes how to use the PRINTBINDINFO utility to print an analysis 
of the binding information of a code file. 

Appendix A. Warning and Error Messages 

This appendix lists the various warning and error messages and their meanings, 
and provides solutions for the errors when applicable. 

Appendix B. Using Binder Control Record Options 

This appendix describes how to use Binder control record options to control the 
processing of Binder input files and the content of the resulting bound code file. 
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Appendix C. Understanding Railroad Diagrams 

This appendix describes the notation used throughout this manual to represent 
the syntax of the Binder language. 



Related Product Information 

The following documentation provides details for using Command and Edit 
(CANDE) and Work Flow Language (WFL) which you use to write and execute 
Binder files. 

A Series CANDE OperaUona R^erence Memual (form 8600 1500) 

This manual describes how CANDE operates to allow generalized file preparation 
and updating in an interactive, terminal-oriented environment. This manual is 
written for a wide range of computer users who work with text and program 
files. 

A Series Work Flow Langut^fe (WFL) Progrtwuning R^erenee Manual (form 
8600 1047) 

This manual presents the complete syntax and semantics of WFL. WFL is used to 
construct jobs that compile or run programs written in other languages and that 
perform library maintenance such as copying files. This manual is written for 
individuals who have some experience with programming in a block-structured 
language such as ALGOL and who know how to create and edit files using 
CANDE or the Editor. 



8600 0304-000 



vii 



Contents 



About This Manual v 



Section 1. Understanding the Binding Process 

What Is Binder? 1-1 

Binder Code File Restrictions 1-1 

Binder input Files 1-2 

The Primary Input File 1-2 

The Host Program 1-3 

The Subprogram 1-3 

Binder Output Files 1-4 

Avoiding Unresolved External References in tlie Bound Code 

File 1-5 

invoicing Binder 1-6 

Invoking Binder from CANDE 1-6 

Invoking Binder from WFL 1-7 

Reserved Words 1-7 

Binder Execution 1-7 

Binding Subprograms 1-8 

Encountering Errors 1-8 

Using Binder Efficiently 1-9 

OIHect-Code Efficiency 1-9 

Section 2. Binder language Constructs 

File Specifier 2-1 

identifier 2-3 

intrinsic Specification 2-3 

Subprogram Identifier . 2-5 

Section 3. Binder Statements 

BIND Statement 3-2 

DONTBiND Statement 3-5 

Conflicts between BIND and DONTBIND Statemento 3-6 

EXTERNAL Statement 3-7 

HOST Statement 3-7 

iNITiALiZE Statement 3-8 

PURGE Statement 3-9 

STOP Statement 3-9 

USE Statement 3-10 

8600 0304-000 Ix 



Contents 



Section 4. Binding Programs Written in the Same Language 

ALGOL intralanguage Binding 4-1 

Compiling ALGOL IHost Prc^rams and Subprogram 4-1 
Declaring Global items within an ALGOL Procedure 

4-2 

Using the Braclcets Method 4-2 

Using the INFO File IVIethod 4-3 

Adding New Global Items to an ALGOL Host Program 

4-3 

Using the ALGOL Separate Compilation Facility 4-4 

Library Binding in ALGOL 4-4 

Record Binding in ALGOL 4-5 

Example of ALGOL Intralanguage Binding 4-5 

Example of Binding an ALGOL Library 4-6 

Example of Binding an ALGOL Program That 

References a Library 4-7 

C intralanguage Binding 4-9 

Compiling C Host Programs and Subprograms 4-9 

Describing Functions and Variables 4-9 

Example of C Intralanguage Binding 4-9 

COBOL Intralanguage Binding 4-10 

Compiling COBOL Host Programs and Subprograms 

4-11 

Binding an External Procedure to a COBOL Host 

Program 4-11 

Activating Bound Subprograms 4-11 

Global Declarations in Subprograms 4-11 

OWN Declarations in the Subprc^ram 4-12 

Library Binding in COBOL 4-13 

Example of COBOL Intralanguage Binding 4-13 

FORTRAN Intralanguage Binding 4-15 

Compiling FORTRAN Host Programs and 

Subprograms 4-15 

FORTRAN Common Blocks 4-16 

Library Binding in FORTRAN 4-16 

Example of FORTRAN intralanguage Binding 4-16 

FORTRAN?? Intralanguage Binding 4-17 

Compiling FORTRAN?? Host Programs and 

Subprograms 4-1? 

Files 4-18 

Common Blocks 4-18 

Library Binding in FORTRAN?? 4-18 

Example of FORTRAN?? intralanguage Binding . . . 4-18 

PL/I Intralanguage Binding 4-21 

Declaring Host Programs and Subprograms 4-21 

STATIC EXTERNAL Variables 4-21 

Example of PL/i intralanguage Binding 4-23 



X 



86000304-000 



Contents 



Section 5. Binding Programs Written in Different Languages 



ALGOL-COBOL Interlanguage Binding 5-2 

Global Items 5-3 

Parameters 5-3 

Libraries 5-3 

Record Binding 5-3 

Binding ALGOL and COBOL74 Programs That Use 

COIVIS 5-4 

ALGOL-FORTRAN interlanguage Binding 5-5 

Parameters 5-6 

Global Items 5-7 

Files 5-7 

Common Blocks 5-7 

Simulating Common Blocks in ALGOL 5-8 

Accessing FORTRAN Common Blocks as ALGOL 

Arrays 5-8 

Accessing ALGOL Global Arrays from a 

FORTRAN Common Block 5-9 

Example of ALGOL-FORTRAN Binding 5-10 

ALG0L-F0RTRAN77 Interlanguage Binding 5-11 

Global Items 5-12 

Subprograms 5-13 

Files 5-13 

Common Blocks 5-14 

Accessing FORTRAN77 Common Blocks as 

ALGOL Arrays 5-14 

Using Initial Values with Common Blocks 5-15 

Accessing ALGOL Arrays from a FORTRAN77 

Common Block 5-15 

Simulating Common Blocks in ALGOL 5-16 

Parameters 5-16 

Example of Binding an ALGOL Subprogram Into a 

FORTRAN77 Host Program 5-18 

Example of Replacing a FORTRAN77 Character 

Function by an ALGOL Procedure 5-19 

Example of Binding F0RTRAN77 Program Units Into 

an ALGOL Host Program 5-20 

ALGOL-NEWP interlanguage Binding 5-21 

ALGOL-Pascal Interlanguage Binding 5-22 

Global Items 5-24 

Parameters 5-25 

Examples of Binding An ALGOL Subprogram into a 

Pascal Host Program 5-25 

COBOL-FORTRAN Interlanguage Binding 5-27 

Global items 5-28 

Parameters 5-29 

C0B0L-F0RTRAN77 Interlanguage Binding 5-29 

Global Items 5-30 

Parameters 5-31 



8600 0304-000 



xi 



Contents 



Example of Passings FORTRAN?? Character 

Variable to a C0B0L?4 Section 5-31 

COBOL-Pascal Interlanguage Binding 5-33 

Global Items 5-35 

Parameters 5-36 

Example of Binding a C0B0L74 Procedure Into a 

Pascal Host Program 5-37 

Example of Binding a COBOL Procedure Into a 

Pascal Host Program 5-38 

FORTRAN-FORTRAN?? Interlanguage Binding ... 5-39 

Subprograms 5-39 

Common Blocks 5-40 

Parameters 5-40 

Characters 5-41 

Libraries 5-41 

Example of Binding a FORTRAN Common Block Into 

a FORTRAN?? Host Program 5-41 

Example of Interlanguage Binding Involving 

FORTRAN??, COBOL74, and ALGOL 5-42 

Section 6. Binding Intrinsics 

What Is an Intrinsic? 6-1 

Compiling Intrinsics 6-1 

Creating a Binder Input File 6-1 

Intrinsic Specification 6-2 

Section 7. Binding Programs That Access Databases 

Binding DMSII Databases . . . . ?-l 

Binding SIM Databases ?-l 

SIM Data Types ?-2 

Referencing a SIM Database ?-2 

Referencing a SIM Entity Reference Variable in a 

Host Program ?-4 

Referencing a SIM Query Variable in a Host Program 

?-5 

Adding Query Variables as New Globals ?-6 

Referencing a SIM Database in a Pascal Host ?-? 

Sections. Printing Binding Information 

Generating Binding Information 8-1 

Using the PRINTBINDINFO Utility 8-2 

Printing Binding Information for Specific Procedures 8-4 

Output Options 8-5 

Appendix A. Warning and Error Messages 



xii 



86000304-000 



Contents 



Appendix B. Using Binder Controi Record Options 

Binder Control Record Format B-1 

Binder Options B-4 



Appendix C. Understanding Raiiroad Diagrams 



What Are Railroad Diagrams? C-1 

Constants and Variables C~2 

Constraints C-2 

Vertical Bar C-3 

Percent Sign C-3 

Right Arrow C-3 

Required Items C-3 

User-Selected Items C-3 

Loop C-4 

Bridge C-4 

Following the Paths of a Railroad Diagram C-5 

Railroad Diagram Examples with Sample Input — C-6 



Glossary 

Bibliograpliy 

index 



8600 0304-000 



xiii 



Figures 

2-1. Subprogram Nesting Structure 



8600 0304-000 



Tables 



1-1. Allowable Binding Combinations 1-2 

1-2. Reserved Words 1-7 

1-3. Binder Action on Subprograms Named in the Host Program 1-8 

3-1. Binder Statements 3-1 

5-1. Allowable Binding Combinations 5-1 

5-2. Corresponding Identifier Types between ALGOL and COBOL 5-2 

5-3. Corresponding Identifier Types between ALGOL and FORTRAN 5-5 

5-4. Corresponding Identifier Types between ALGOL and FORTRAN?? 5-12 

5-5. Corresponding Identifier Types between ALGOL and Pascal 5-22 

5-6. Corresponding Identifier Types between COBOL and FORTRAN 5-2? 

5-?. Corresponding Identifier Types between COBOL and FORTRAN?? 5-29 

5-8. Corresponding Identifier Types between COBOL and Pascal 5-33 

5-9. Corresponding Identifier Types between FORTRAN and FORTRAN?? . . 5-39 

B-1. Binder Control Record Options B-4 



8600 0304-000 xvii 



Section 1 

Understanding the Binding Process 



What Is Binder? 

Binder is a utility that lets you permanently insert a module from one compiled 
program into another compiled program. The module you want to insert is called 
a subprogram. The program in which you are inserting the subprogram is called 
the fwst program. Binder lets you combine subprograms and host programs 
written in the same language or in a variety of different languages. Table 1-1 
shows the allowable binding combinations. 

By using Binder, you can change or correct an existing program without having 
to rewrite or recompile the entire program. For example, if a program accesses 
several subprograms, and some require changes, you can revise and recompile 
only the subprograms that need changes, and then use Binder to combine the 
subprograms into one resultant program. This process saves computer time in 
recompiling and programmer time in rewriting. 

Binder also allows you to use a standard set of subprograms with multiple other 
programs. You need to write the subprograms only once. Then, you can bind them 
into the other programs whenever you need to do so. 

Binder Code File Restrictions 

You cannot bind code files that are more than three system software releases 
older than the release level of the Binder program with which you are working. 
For example with the Mark 3.9 release of Binder, you can only bind code files of 
Mark 3.6 or later. If you use a code file that is too old. Binder flags the file with 
an error message and terminates. 

If you use your compiler to generate code that runs on a restricted set of 
computers, the resulting bound code file will run only on the computers on which 
the host program and the bound subprograms run. For example, if one code file 
runs on an A 4 and an A 16 and another code file runs only on an A 4, the bound 
code file will run only on the A 4. 
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Table 1-1. Allowable Binding Combinations 



Subprogram 
Language 


Host Program Language 


ALGOL^ 


C 


COBOL 


FORTRAN 


FORTRAN?? 


NEWP* 


Pascal* 


PL/I 


ALGOL+ 


Yes 




Yes 


Yes 


Yes 


Yes 


Yes 




C 




Yes 














COBOL 


Yes 




Yes 


Yes 


Yes 




Yes 




FORTRAN 


Yes 




Yes 


Yes 


Yes 








F0RTRAN77 


Yes 




Yes 


Yes 


Yes 








PL/I 
















Yes 



All references to ALGOL include the various extensions of ALGOL, such as BDMSALGOL. DCALGOL, and 
DMALGOL. 



* The NEWP Master Control Program (MCP) can serve only as a host program in binding. 
^ Pascal programs can serve only as host programs in binding. 

Binder Input Files 

In a normal execution, you supply Binder with the following input: 

• A primary input file (optional) 

• A compiled host program 

• One or more externally compiled subprograms 

The Primary Input File 

The primary input file is an optional file that consists of Binder statements and 
Binder control records. You can use Binder statements to indicate the titles of the 
subprograms and the title of the host program to be bound. You can also use 
Binder statements to exclude certain subprograms from the binding process. You 
can use Binder control records to control the way Binder processes the 
subprogram and the host program, and to determine the content of various files 
produced during binding. Binder statements are described in Section 3. Binder 
control records are described in Appendix B. 

The internal name of the primary input file is CARD. If you initiate the bind from 
WFL, the file kind is READER. If you initiate the bind from CANDE, the file kind 
is DISK, unless you use a file equation. 
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The Host Program 

The host program is the code file to which subprograms can be bound. A host 
program must contain the first executable code segment of a program. A host 
program can be the resultant code file of a previous bind. 

You can specify the title of the host file to Binder by using the Binder HOST 
statement (see Section 3) or by file equating file HOST in the WFL or CANDE 
syntax used to start Binder. The internal name of the host program is HOST. The 
file kind is DISK, unless you change the file kind with a file equation. You must 
always supply a host program, except when binding intrinsics. For details about 
binding intrinsics, see Section 6. 

Some examples of host programs are as follows: 

• An ALGOL outer block 

• A FORTRAN program containing a main program 

• The MCP 

• A PL/I procedure 

• A COBOL program compiled with the LEVEL option set to 2 

• A previously bound program 

• A FORTRAN?? program with $ BINDINFO set 

• A Pascal program with modules declared EXTERNAL 

• AC program containing the function, "main." 

The Subprogram 

A subprogram is a separately compiled program unit that exists externally to the 
host program. You must compile external subprograms with the appropriate 
language compiler before binding them to a host program. Note that a 
subprogram cannot be the resultant code file of a previous bind. Multiple 
subprograms can exist in a subprogram file. 

External subprograms are referenced in the host program but have not yet been 
bound. You do not have to specify external subprograms in the BIND statement, 
because they are bound automatically by default. 

Binding makes the subprogram a part of the host program. When you bind a new 
version of the subprogram, the new version replaces the existing version in the 
host program. This procedure is known as replacement binding. 
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Some examples of subprogram files are as follows: 

• ALGOL procedures 

• FORTRAN?? subroutines or functions 

• Separately compiled procedures of the MCP 

• Intrinsics 

• PL/I procedures 

• COBOL programs compiled with the LEVEL option set to 
a value greater than 2 

• C functions 

The ALGOL, FORTRAN, FORTRAN??, and PL/I compilers title subprograms 
compiled through WFL by replacing the identifier following the last slash of the 
code file title in the WFL COMPILE statement with the subprogram name. In 
COBOL, the subprogram name is taken from the identifier following the last slash 
of the code file title in which the subprogram resides. 

In ALGOL, FORTRAN, and FORTRAN??, a LIBRARY compiler control option is 
available that causes the compiler to place all subprograms compiled in a single 
compilation into one code file. The title of the code remains as specified in the 
COMPILE statement. The LIBRARY option is automatically set to TRUE when the 
compilation of an ALGOL program with one or more independent procedures is 
initiated by CANDE, or when the compilation of a FORTRAN or FORTRAN?? 
program with the SEPARATE compiler control option set to TRUE is initiated by 
CANDE. 

Binder Output Files 

Binder can produce three files during normal execution: 

• A bound code file 

A file consisting of the host program and the subprograms bound into the 
host program. 

All of the deimplementation warnings produced for the individual code files 
are included in the bound code file. In addition, the bound code file might also 
contain unresolved references to external programs. Unresolved external 
references occur when subprograms referenced in the host do not get bound. 
Unresolved external references are discussed later in this section. 

The internal file name for the bound code file is CODE. The file kind is DISK; 
you cannot change the file kind with a file equation. 

• An optional printer listing 

A printer listing whose contents vary depending upon the Binder control 
record options you specify. To produce a printer listing, include the LIST or 
TIME Binder control record option in the primary input file. 



1-4 



86000304-000 



Understanding the Binding Process 



The internal file name for the printer file is LINE. The file kind is PRINTER 
unless you change the file kind with a file equation. 

• An optional error file 

The error file, labeled ERRORS by default, contains all the error messages 
produced during the binding process. To generate an error file, include the 
ERRORLIST Binder control record option in the input file you use to invoke 
Binder. 

If you initiate Binder from WFL, the file kind is PRINTER. If you initiate 
Binder from CANDE, the file kind is REMOTE, unless you change the kind 
with a file equation. 

Avoiding Unresolved External References in the 
Bound Code File 

A reference to an external subprogram is in a resolved state when the 
subprogram is successfully bound to the host program. An external reference is in 
an unresolved state when the subprogram does not get bound to the host 
program. 

External subprograms do not get bound to the host program if 

• Binder cannot locate the subprogram 

• You use the Binder EXTERNAL statement in the host program to prevent the 
subprogram from being bound 

Unresolved references to external subprograms are fatal to program execution if 
the program tries to access the unbound subprogram. Program execution is not 
affected if the program does not attempt to access the unbound subprogram. 

You can help prevent fatal program errors due to unresolved external references 
by including the WAIT, STRICT, and LIST Binder control record options in the 
primary input file. 

WAIT Causes Binder to suspend binding when it cannot find a 

specified subprogram. You can then make the subprogram 
available and resume binding, or you can terminate Binder. 

STRICT Prevents the resultant code file from being locked if a 

specified subprogram is not bound. 

LIST Produces a printer listing that you can use to verify that 

all necessary subprograms have been bound before you 
attempt to execute the program. 

For details about Binder control record options, see Appendix B. 



8600 0304-000 



1-5 



Understanding the Binding Process 



Invoking Binder 

There are two ways to invoke Binder: 

• By using the CANDE command, BIND, to activate the primary input file (a 
work file or disk file containing Binder statements) 

• By using a WFL job that contains Binder statements 

Refer to Section 3 for the syntax and explanation of the Binder statements. 

When the bind is complete, Binder gives the time of the compilation, as well as 
the compiler name and version number for the subprograms and the host 
program. 

Invoking Binder from CANDE 

Your primary input file must contain BIND statements to indicate the location of 
the subprograms to be bound. The input file can optionally indicate the name of 
the host program to which the subprograms are being bound. If the input file 
does not contain the name of the host program, you must indicate the host 
program name by using a file equation in the CANDE BIND command. 

For example, assume that you have the following CANDE file, named 
BOUND/LIB, as the primary input file: 

HOST IS OBJECT/BOUND/LIB/HOST; 

BIND SUBA FROM OBJECT/BOUND/LIB/PASSR; 

BIND SUBB FROM OBJECT/BOUND/LIB/PASSR; 

To invoke Binder, you would enter 

BIND BOUND/LIB 

Assume that the HOST statement was not included in the BOUND/LIB file, and 
instead, the file looked like the following: 

BIND SUBA FROM OBJECT/BOUND/LIB/PASSR; 
BIND SUBB FROM OBJECT/BOUND/LIB/PASSR; 

In this case, the command to invoke Binder would be 

BIND BOUND/LIB; BINDER FILE HOST-OBJECT/BOUND/LIB/HOST 

For both of the preceding command examples, the resultant bound code file 
would be titled OBJECT/BOUND/UB. 

Refer to the CANDE Operations Reference Mantml for the complete syntax and 
description of the BIND command. 
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Invoking Binder from WFL 

You can list Binder statements in a WFL job, and then use the WFL job to initiate 
the bind, as shown in the following example. 

? BEGIN JOB BIND/SYSTEM/MYLIB 
BIND SYSTEM/MYLIB BINDER LIBRARY; 
BINDER DATA 

HOST IS OBJECT/BOUNO/LIB/HOST; 
BIND SUBA FROM OBJECT/BOUND/LIB/PASSR; 
BIND SUBB FROM OBJECT/BOUND/LIB/PASSR; 
? END JOB. 

The resultant bound code file would be titled SYSTEM/MYLIB. 

Reserved Words 

The following list contains words that are reserved for use in Binder syntax. You 
cannot use these words for any purpose other than that described in this manual. 



Table 1-2. Reserved Words 



BIND 


FROM 


OF 


DONTBIND 


HOST 


PURGE 


EXTERNAL 


INITIALIE 


STOP 


FOR 


IS 


USE 



Binder Execution 

Binder begins execution by reading the primary input file (CARD), if one exists. 
If Binder finds a primary input file, it processes and stores the Binder statements 
for future reference. If Binder detects any syntax errors during the processing, it 
terminates after reading the last input record of the file. If a primary input file 
does not exist. Binder attempts to open the host program and read the first 
record. 

If the host program is not present or cannot be made present, the operating 
system discontinues Binder. If the host program is not a code file or is otherwise 
not suitable for binding, the appropriate error message appears and Binder 
terminates. 

If Binder finds a host program, it locates and reads the Binder information 
contained therein. Binder determines if each named subprogram is bound or 
unbound, and then determines whether a statement from the primary input file 
applies to the subprogram. As a result of this examination. Binder takes the 
actions shown in Table 1-3. 
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Table 1-3. Binder Action on Subprograms Named in the Host Program 



Primary Input File 


Bound 


External (Unbound) 


Statement 


Subprogram 


Subprogram 


No statement 


Ignores subprogram 


Attempts to bind 






subprogram 


DONTBIND statement 


Ignores subprogram 


Ignores subprogram 


BIND statement 


Binds subprogram and 


Binds subprogram 




discards previously bound 






subprogram (replacement 






binding) 





Binding Subprograms 

When directed to bind a subprogram, Binder attempts to find the correct file 
where the subprogram resides. If the correct file is not present on disk and 
neither the STRICT nor WAIT options are specified, Binder ignores the 
subprogram, sends a message indicating that it was unable to access the file, and 
continues to look for other subprograms to bind. (For more information about the 
STRICT and WAIT options, refer to Appendix B.) 

If Binder is directed to a host program or to the resultant code file of a previous 
bind, Binder sends a message indicating that the file is suitable only as a host and 
does not bind the given subprogram. Binder continues to look for other 
subprograms to bind. 

When Binder finds a file containing a subprogram, it first verifies that the file 
contains the necessary information for binding. Binder also verifies that the 
subprogram matches the description of what is expected by the host. If the type 
of subprogram, its number or type of parameters, or its execution level does not 
match its declaration in the host, Binder discontinues binding the subprogram, 
returns to its previous level of binding, and continues to look for other 
subprograms to bind. 

Encountering Errors 

Once Binder finds a subprogram that matches the host description, any 
subsequent error conditions arising during the bind of that subprogram are 
usually fatal, and binding is discontinued. 

Errors occur during the binding process when Binder finds a mismatch between 
the description of a global reference made in the subprogram and its 
corresponding description in the host progriam. Certain languages allow minor 
discrepancies in type matching, such as referencing a variable as a real number in 
the subprogram when it is declared as an integer in the host. However, more 
serious mismatches, such as referencing a single-precision variable as an array or 
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calling another subprogram with the wrong number of parameters, are flagged as 
fatal errors. 

Using Binder Efficiently 

Most of Binder's execution time is used to perform input and output operations. 
For this reason, the most efficient way to use Binder is to maintain a host 
program that contains a completely bound program. When you need to update an 
existing subprogram, you change the code, recompile the subprogram, and then 
replace the existing subprogram in the host program by binding in the new 
version. This method, called replacement binding, requires that only two files be 
accessed, greatly reducing the I/O time used. 

If your host program is not a completely bound program, you can waste a great 
deal of I/O time. For example, if you have an unbound host program and 250 files 
that contain subprograms to be bound to it, you have to rebind all the files each 
time you update one subprogram. To bind the host program and the subprograms 
together requires the opening and closing of 251 files with corresponding buffer 
allocations and deallocations, as well as the I/O time to read and write the files. 
You could reduce the number of files by using the LIBRARY option available in 
some compilers to combine several subprograms into one library code file. 
However, using this option is not as effective as maintaining a bound program. 

Object-Code Efficiency 

In general, the bound code file produced by Binder is equivalent to the code file 
produced by a language compiler. In the case of replacement binding, a process in 
which an existing subprogram is replaced by binding in a new subprogram, 
Binder reuses some segment dictionary locations used exclusively by the 
Subprograms being exchanged. However, code segments not needed by the new 
subprogram might remain in the bound code file. These obsolete code segments do 
not affect the execution of the bound code but do occupy storage space. 

Once added to a bound program, items at lexical (lex) level 2 are never removed. 
For example, if a subprogram containing variables declared as OWN or STATIC is 
replaced, the lex level-2 locations for the one or more variables declared as OWN 
in the replaced subprogram are not reused. New lex level-2 locations can be 
allocated for the subprogram that replaces the existing subprogram. (Although 
variables declared as OWN exist at lex level 2, they are accessible only to the 
program unit that declares them; thus, if this program unit is replaced, the lex 
level-2 locations are inaccessible.) 

Usually the unreferenced lex level-2 stack locations belonging to replaced 
subprograms cause very little overhead in execution or in core usage. However, if 
an initialized array, which is an array containing initial values other than 0 
(zero), is declared as OWN, the code to initialize the array causes the array to be 
made present. Therefore, repeated replacement binding of a subprogram that 
contains initialized arrays can cause some additional core usage and can increase 
execution time. 
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Section 2 

Binder Language Constructs 



This section describes the syntactic items that appear in the syntax diagrams in 
Section 3 of this manual. 



File Specifier 



Syntax 



Use the file specifier construct to indicate the name of a file. 



<file specifier> 



- (<usercode>) — 
_ * 



^12^^ — <naine> 



or 

ON - <fami 



ly naine> —I 



<naine> 



E<letter> — p 
<digit> —I 



16'^ 1- <letter> 

<d1g1t> - 



- <hyphen> 

- <underscore> 



EBCDIC character> 



1.. 



<fain11y naiiie> 



<nonquote ident1f1ep> 

- PACK 

_ DISK 
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Explanation 



<letter> 



Any one of the 26 uppercase characters, A through Z 



<digit> 



Any character in the range 0 (zero) through 9 



<hyphen> 



The hyphen character (-) 



<underscore> 



The underscore character (_) 



<name> 



A string of characters used to identify an entity such as 
a file, a usercode, or a device group. 



<EBCDIC> 



Any EBCDIC character for which the hexadecimal code 
is greater than or equal to hexadecimal 40 and is not 
the EBCDIC quotation mark character (") 



<usercode> 



A name whose purpose is to establish user identity, to 
control security, and to provide for segregation of files 



<family name> 



An identifier that specifies the group of disk storage 
devices that function as one logical unit. 



<nonquote identifier> A string of 1 to 17 alphanumeric characters 
alphanumeric character Any of the characters A through Z or 0 (zero) through 9 



In a file specifier, all of the names except the last indicate the directory in which 
a file is located. The last name is the actual file name. For example, in the file 
specifier A/B/C, A/B is the directory name, and C is the file name. 

The file specifier can be optionally preceded by a usercode (enclosed in 
parentheses) or by an asterisk (*). A family other than the default family (which 
usually is DISK) can be specified by using the suffix^ ON <family name>. 

The name and the family name can consist of 1 through 17 alphanumeric 
characters and cannot be split across input record boundaries. 

If you use an equal sign (=) as part of the directory name. Binder replaces the 
equal sign with the subprogram name. For example, if the directory name is 
A/B/— and the subprogram is S, Binder looks for a file titled A/B/S. If multiple 
files have the same directory name, as in A/B/SUB, A/B/PROG, A/B/ALG, Binder 
examines each of the specified files in order of appearance to determine if the file 
contains the subprogram to be bound. 



Details 
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Examples 

A/B/= 

(MYUSERCODE)TEST/= 
*- ON TESTPACK 
A/B/C 

FILEID1/FILEID2/FILEID3 ON MYPACK 



Identifier 



Use the identifier construct to indicate the name of a file, subprogram, or 
program variable. 



<i(lentifier> 



Explanation 



An identifier consists of any combination of the following characters, optionally 
enclosed in quotation marks. You cannot split an identifier across input record 
boundaries. 

A through Z - (hyphen) 

a through z @ (commercial at) 

0 (zero) through 9 / (slash) 

_ (underscore) $ (dollar sign) 

' (single quote) # (pound sign) 

. (period) 



Intrinsic Specification 



Use the intrinsic specification construct to indicate the name of an installation 
intrinsic to be bound. 



Syntax 

<intrinsic specification> 

- <subprograin 1clentifier> - « - <intrins1c number pair> - <1anguage 1ist> 



<intrinsic number pair> 
- <integer> - , - <integer> 



8600 0304-000 



2-3 



Binder Language Constructs 



<1anguage 1ist> 
|4 . ■ 



- ( 



ALGOL 



- COBOL - 

- DCALGOL - 

- FORTRAN - 

- NEWP — 

- PL/I 



Explanation 



<intrinsic number 
pair> 



<language list> 



Specifies an intrinsic number pair. The first integer of 
the intrinsic number pair specifies an installation 
number, which can range in value from 0 through 2046; 
however, numbers 0 through 99 are reserved for system 
use. The second integer specifies an intrinsic number, 
which can range in value from 0 through 8191. No two 
intrinsics within an intrinsic file can have the same 
intrinsic number pair. 

Specifies a list of those compilers authorized to 
reference a given intrinsic. A referencing language is 
not necessarily the same as the language in which the 
intrinsic is written. The DCALGOL language identifier 
allows a specified intrinsic to be accessed by the 
DMALGOL compiler as well as by the DCALXiOL 
compiler. 



Details 



Standard system intrinsics that are referenced as EXTERNAL in a program are 
automatically bound. Thus, you do not need to declare such system intrinsics in a 
BIND statement. See Section 6 for details on binding intrinsics. 



Examples 



$ SET INTRINSICS 
BIND - FROM INTR/-; 

BIND MYSIN =101, 1 (ALGOL, FORTRAN) FROM INTL/-; 

BIND COFFEE » 102, 2 (COBOL) FROM POT; 

STOP; 
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Subprogram Identifier 

Use the subprogram identifier construct to indicate the name of a subprogram. 



r 



29> OF 



— I— <identifier> 



Explanation 

The identifier construct is defined earlier in this section. 



Details 



If you have subprograms with the same name, you must use identifiers to 
uniquely identify, or qualify, the subprograms. 

A subprogram identifier can contain a maximum of 30 identifiers. A level of 
nesting cannot be skipped when a subprogram is qualified. 

When a subprogram identifier is used in a Binder statement, the Binder statement 
is applicable to all subprograms that fit the qualifications of the subprogram 
identifier. 



Figure 2-1 illustrates the nesting structure of a program. 
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OB. 



<1> 
P(2) 



P(3) 
P(4) 



Q(5) 
P(6) 



Q(7) 
P(8) 



R(9) 



P(10) 



js(ii) 



'Declared as EXTERNAL 



Qualification 
P 

POFP 

P OF P OF P 

POFQ 

P OF O.B. 

R 

S 

P OF R OF OOF O.B. 

POFR 

SOFQ 



Item Referred to 
by Qualification 

2 

3 

4 

8 

2 

9 
11 
10 
10 



none 



Figure 2-1. Subprogram Nesting Structure 



The program shown in Figure 2-1 declares one external subprogram R 
(subprogram R is declared in subprogram Q that resides in the host), plus the 
structure of the separately compiled subprogram R. As R is bound into the host, 
all subprogram identifiers become applicable to subprograms nested within R as 
well as to those subprograms initially residing in the host. Each subprogram is 
given a number in the example so that it can be uniquely identified. O.B. is the 
name given to the unnamed outer block so that it can be used as a qualifier. 
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Examples 

PROC-ONE 
REC-l-LEN 
P OF Q 

TEST-5 OF TEST-4 OF TEST-3 
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Section 3 

Binder Statements 



Binder statements let you initiate certain binding operations or specify file names 
or identifiers to be used in the binding process. 

You specify Binder statements in the primary input file in free form on one or 
more records. Place a semicolon (;) after each statement. 

A percent sign (%) appearing in any column from 1 through 72 of a record directs 
Binder to ignore the remaining columns of the record. Binder automatically 
ignores columns 73 through 80. 

An example of a Binder primary input file within a WFL job is shown below. The 
primary input file is indicated in italic type. 

? BEGIN JOB BIND/RESULT; 

BIND C0B0L74/EXAMPLE BINDER; 

BINDER DATA; 

HOST IS C0B0L74/H0ST; 

USE SI FOR PROG; 

BIND SI FROM C0B0L74/PR0G; 

STOP; 
? END JOB. 

The various Binder statements are shown in Table 3-1. The syntax and examples 
for each statement are provided in this section. 



Table 3-1. Binder Statements 



Statement 


Description 


BIND 


Indicates the name of a subprogram or Intrinsic to be bound, the 
title of the file containing the subprogram or intrinsic, or both 


DONTBIND 


Directs Binder not to bind a specified subprogram 


EXTERNAL 


Nonpreferred synonym for DONTBIND. 


HOST 


Indicates the name of the host program to which a subprogram 

will be bound 


INITIALIZE 


Specifies the address couple of a Master Control Program (MCP) 
global item for intrinsic binding 


PURGE 


Causes the file or group of files indicated by the file specifier to 
be removed from disk after binding 
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Table 3-1. Binder Statements (cont.) 



Statement 


Description 


STOP 


Indicates the end of the primary input file 


USE 


Matches the identifiers of external subprograms with the 
identifiers in the host program 



BIND Statement 



Syntax 



Use the BIND statement to specify the name of a subprogram or intrinsic to be 
bound, the title of the file where the subprogram or intrinsic can be found, or 
both. 



- BIND 



<subprograin Identifiers 



L- xintrlnsic specifications 
- - •- <f rom part> — — ■■ 



TT ] 

-* *— <froro part> -* 



L ? FROM - <fne specifiers 
<from parts 



r 



FROM -J — • <fne specifiers 



Explanation 



For an explanation of the metatokens in the preceding syntax diagram, see 
Section 2. 



Details 



Using the BIND„J'ROM,., Form of the BIND Statement 

With the BIND <subprogram idewtifier> FROM <JUe specifijer> construct, you 
can specify only one subprogram identifier, unless the file specifier names a 
library file (an ALGOL, FORTRAN, or FORTRAN?? program compiled with the 
LIBRARY option set to TRUE). 

Replacement Binding 

You can use the BIND statement to bind in a new version of a subprogram 
already bound to a host. This action is called repUwement binding. 
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(Replacement binding is not possible with a C program. Refer to "C Intralanguage 
Binding" in Section 4 for more information.) 

Binding External Subprograms 

It is not necessary to use a BIND statement to declare external subprograms 
(those not already bound to the host). Rather, you can declare the subprograms 
as external in the host program, and use the BIND = form of the BIND statement 
to indicate the file that contains the subprograms to be bound. 

Using the BIND ^ Form of the Bind Statement 

You should use the BIND == construct when a subprogram identifier is specified 
in a BIND statement and no file is provided. Binder attempts to locate the file 
containing the subprogram by using the directory names declared in this 
construct. Binder replaces the equal sign (=) with the name of the subprogram to 
be bound. 

You can supply only one BIND = statement to Binder. If you supply more than 
one, only the last statement is used. 

If a BIND = statement is required for proper binding, but you did not include 
that statement in the CARD input file, Binder creates a BIND = statement by 
using the host program title and substituting the last identifier with an equal 
sign. For example, if the host program has the title THIS/IS/MY/HOST, Binder 
creates the following statement: 

BIND = FROM THIS/IS/MY/= 

After creating a BIND = statement, Binder replaces the equal sign with the 
subprogram name and looks for a file with that title. For example, if PF is the 
subprogram to be bound, the BIND statement assumes the following form: 

BIND PF FROM THIS/IS/MY/PF 

Binder looks for subprogram PF in the file titled THIS/IS/MY/PF and binds the 
subprogram if it is found. 

During intrinsic binding when no host program is used, Binder creates the BIND 
— statement by substituting the code file title for the host program title. 

Using the BIND ? Form of the BIND Statement 

The BIND ? FROM <file specifier> form of the BIND statement binds a 
subprogram written in C to a host program written in C. This construct lets you 
bind all functions exported from the specified file into the host without having to 
specify the functions with the BIND <subprogram identifier> construct. For 
example, if file A contains the functions X, Y, and Z, you can bind all the 
functions by using either of the following statements: 

BIND ? FROM A; 

BIND X, Y, Z FROM A; . 



8600 0304-000 



3-3 



Binder Statements 



Examples 

The following example binds subprogram SUBA with subprogram P, which is 
nested in subprogram Q. For details on subprogram nesting structure and 
restrictions, refer to "Subprogram Identifier" in Section 2. 

BIND SUBA, P OF Q 

The following example directs Binder to bind subprograms SUBA and SUBB from 
an ALGOL library file labeled ALGOL/UBFILE. 

BIND SUBA, SUBB FROM ALGOL/LIBFILE 

The following example directs Binder to bind subprogram SUBA from the file 
A/B/C. 

BIND SUBA FROM A/B/C 

The following example directs Binder to bind subprograms SUBA, SUBB, and 
SUBC from the files A/SUBA, A/SUBB, and A/SUBC, respectively. 

BIND SUBA, SUBB, SUBC FROM A/» 

The following example directs Binder to look for subprogram SUBA first in 
TESTl/SUBA, and then in TEST2/SUBA. Then Binder looks for subprogram 
SUBB first in TESTl/SUBB, and then in TEST2/SUBB. 

BIND SUBA, SUBB FROM TESTl/», TEST2/= 

The following example directs Binder to bind subprogram SUBA nested in SUBX, 
and subprogram SUBB nested in SUBY, from the file TEST/FILE. 

BIND SUBA OF SUBX, SUBB OF SUBY FROM TEST/FILE 

In the following example, Binder looks in the file, THISFILE, for any external 
subprograms and for any subprograms declared in a BIND statement without a 
corresponding file specifier. Binder replaces the equal sign with the name of the 
subprogram. 

BIND > FROM THISFILE 

Assuming that there is an external subprogram labeled SUBA, the following 
example directs Binder to look for SUBA first in A/SUBA, next in B/SUBA, and 
then in C/SUBA. 

BIND - FROM A/=,B/=,C/- 

If the subprogram is SUBA, the following example directs Binder to look for 
SUBA in SUBA. 

BIND = FROM = 
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The following examples illustrate how you can specify program files by using the 
BIND <subprogram identifier> and BIND — constructs. Each of the three 
statement groups has the same net effect. 

BIND » FROM FILEID/=; 
BIND P; 
BIND Q; 
BIND R; 



BIND P,Q,R FROM FILEID/»; 

BIND P FROM FILEID/P; 
BIND Q FROM FILEID/Q; 
BIND R FROM FILEID/R; 

If the subprograms, P, Q, and R were external to the host, they would be bound 
by default. Thus the following statement would have the same effect as the 
statements in the previous three examples: 

BIND « FROM FILEID/»; 

DONTBIND Statement 

Use the DONTBIND statement to direct Binder not to bind a specified 
subprogram. You can use the DONTBIND statement to suppress the binding of all 
external subprograms referenced in the host program. 



Syntax 



- DONTBIND 



r 



<subprograin identifier> 



Explanation 



For an explanation of the metatokens in the preceding syntax diagram, see 
Section 2. 

Dataiis 

When you include a subprogram identifier in a BIND statement, but do not 
include a file specifier, Binder uses the host program title to create a file in which 
to possibly locate the subprogram. Binder substitutes the subprogram identifier 
for the last identifier of the host program title and searches for the subprogram 
in the file under this name. The DONTBIND statement is used to suppress this 
process. 



8600 0304-000 



3-5 



Binder Statements 



For example, if a subprogram is declared external to allow it to be invoked by the 
ALGOL statement, CALL, the DONTBIND statement can be used to suppress the 
automatic search for the subprogram reference. In addition, the DONTBIND 
statement can be used if the subprogram is to be bound during a later run of 
Binder. 

Examples 

The following example directs Binder to suppress the binding of the subprograms, 
SUBA and SUB3. The subprograms remain unresolved external references. 

DONTBIND SUBA, SUB3 

The following example directs Binder to suppress the binding of all external 
subprograms referenced in the host program and not explicitly named in a BIND 
statement. All of the subprograms remain unresolved external references. 

DONTBIND = 

Conflicts between BIND and DONTBIND Statements 

If multiple BIND and DONTBIND statements apply to a subprogram. Binder 
selects the statement to use according to the following priority scheme. 

1. Binder uses the statement that contains the subprogram identifier with the 
most qualifiers if the qualification matches the environment of the given 
subprogram. 

2. When a BIND statement and a DONTBIND statement have the same number 
of qualifiers, Binder uses the BIND statement. 

3. When more than one BIND statement applies and each has the same number 
of qualifiers. Binder uses the last BIND statement. (These rules are referred 
to in the following paragraphs as priority rule 1, priority rule 2, and priority 
rule 3.) 

In the following example. Binder selects the BIND statement according to priority 
rule 1. 

DONTBIND - ; 
BIND SUBR; 

In the next example, Binder selects the BIND statement according to priority 
rule 2. 

BIND SUBR; 
DONTBIND SUBR; 

In the following example, potential conflict exists among three BIND statements. 
If subprogram P is nested in subprogram Q, P is bound from file B/C according to 
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priority rule 1. If subprogram P is not nested in subprogram Q, the statement 
BIND POFQ FROMB/C; does not apply, and P is bound from file C/D according 
to priority rule 3. 

BIND P FROM A/B; 
BIND P OF Q FROM B/C; 
BIND P FROM C/D; 

EXTERNAL Statement 



Use the EXTERNAL statement to direct Binder not to bind the specified 
subprogram. 



Syntax 



- EXTERNAL 



r 



Ksubprogram 1dent1fier> 



Explanation 



For an explanation of the metatokens in the preceding syntax diagram, see 
Section 2. 



Details 



If a subprogram is external to the host. It is left as an unresolved external 
reference when the EXTERNAL statement is used. 



The EXTERNAL statement is the nonpreferred synonym for the DONTBIND 
statement. Refer to the DONTBIND statement for a more detailed explanation. 



HOST Statement 

Use the HOST statement to name the title of the host program to which a 
subprogram is to be bound. 

Syntax 

- HOST - IS - <file specif1er> ■ 1 

Explanation 

For an explanation of the metatokens in the preceding syntax diagram, see 
Section 2. 
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Details 

When the HOST statement is used, any file equation that involves the host 
program is overridden. If more than one HOST statement appears in the primary 
input file, only the last HOST statement is effective. 

A HOST statement (or host program equation) is not necessary when binding a C 
program if the host program is specified in a BIND ? statement. The file 
containing the "main" function is implicitly the host program. 

Examples 



HOST IS MY/HOST; 

HOST IS *SYSTEM/PL/I; 

HOST IS (MYUSERCODE) HOST/FILE; 

INITIALIZE Statement 

Use the INITIALIZE statement when binding intrinsics to specify the correct 
address couple of an MOP global item. 

Syntax 



- INITIALIZE -L- <identifier> - « - oddress coup1e> 
oddress couple> 

- ( - <1nteger> - , - <1nt6ger> - ) 

<integer> 

4 



ai^— <digit> 



Explanation 

< digit > Any one of the Arabic numerals 0 (zero) through 9. 

(For an explanation of the other metatokens in the 
preceding syntax diagram, see Section 2.) 

Details 



This statement is necessary because compilers do not have the correct address 
couple of the MOP global item at compiling time. 
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Take extreme care when using the INITIALIZE statement, because unpredictable 
results can occur. 

For details about binding intrinsics, see Section 6. 

ExamplM 

INITIALIZE A - (0.50); 
INITIALIZE BLOCKEXIT - (0,10); 



PURGE Statement 

The PURGE statement causes the file or group of files indicated by the file 
specifier to be removed from disk after Binder has finished processing. 



Syntax 



<purge stateiiient> 
4 



- PURGE 



<file spec1fier> 



Explanation 



For an explanation of the metatokens in the preceding syntax diagram, see 
Section 2. 

Details 

If a file is specified in the PURGE statement but is not successfully bound, it will 
not be removed from disk after Binder has finished. 



Exampias 

PURGE SEP/FILE; 
PURGE 

PURGE FILE1/-.FILE2/-; 

STOP Statement 

Use the STOP statement to indicate the end of the primary input file. The STOP 
statement is optional. 

Syntax 

- STOP — — 
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Details 



Binder ignores all records that follow the STOP statement in the input file. This 
feature allows you to store additional Binder input records in one file without 
having them executed. 



Example 



STOP; 

USE Statement 



The USE statement directs Binder to match a specified identifier in a subprogram 
with a specified identifier in a host program. Use the USE statement when 
identifiers in the subprogram have different names from the identifiers in the 
host program. 



Syntax 



- USE - <identifier> - FOR -L- <identifier> 



r.. 



L OF - <subprograin identifier> J 



Explanation 



For an explanation of the metatokens in the preceding syntax diagram, see 
Section 2. 



Details 

The first identifier following USE is the identifier contained in the host. 

The identifiers following FOR are identifiers referenced by the subprograms to be 
bound into the host. For example, the statement, USE A FOR B,C,D, directs 
Binder to use the host identifier, A, anytime it encounters the subprogram 
identifiers, B, C, or D. 

When a USE statement is invoked and the host identifier does not exist in the 
host program, the identifier referenced by the subprogram is added to the host 
program and given the name of the host identifier as specified in the USE 
statement. The identifier referenced by the subprogram can be qualified by the 
subprogram identifier so that the USE statement is invoked only when the 
specified subprogram is bound. 

Special considerations are necessary when the USE statement includes the 
subprogram name itself. According to file-naming conventions, the identifier 
following the last slash in the subprogram title is the subprogram name. (For 
more information concerning file-naming conventions, refer to "BIND Statement" 
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in this section.) However, when Binder looks for the subprogram through the 
directory name, as in OBJECT/LIB/ =, it looks for a file title ending with the 
subprogram name as found in the host program. 

If Binder is directed to bind a subprogram from a specified file, and it discovers 
that the subprogram identifier does not match the subprogram identifier in the 
host, Binder issues a warning message and creates a USE statement that corrects 
the identifier mismatch. 

Examples 

The following examples set up the following correspondences: 

• Use the host identifier ALGOLARRAY whenever the COMMON block is 
referenced in a FORTRAN or FORTRAN?? subprogram. 

• Use the host identifier A whenever the subprogram identifiers B, C, or D are 
encountered. 

• Use the host identifier Z whenever the subprogram identifier Y is encountered 
in the subprogram identified as SUBR2. 

USE ALGOLARRAY FOR /COMMON/; 

USE A FOR B.C.D; 

USE Z FOR Y OF SUBR2; 

For the following two examples, assume that Q is a subprogram contained in a 
file titled A/Q. If the input to Binder is as shown in the first example, Binder will 
attempt to bind from file A/P. That is, the USE statement does not cause Binder 
to bind subprogram P from file A/Q. The BIND statement included in the second 
example is necessary for correct binding. 

BIND = FROM A/=; 
USE P FOR Q; 
BIND P; 



BIND - FROM A/=; 
USE P FOR Q; 
BIND P FROM A/Q; 
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Section 4 

Binding Programs Written in the Same 
Language 



The process of binding one or more subprograms to a host written in the same 
language is known as intrcUangtiage binding. This section discusses the various 
techniques required to perform intralanguage binding for programs written in 
ALGOL, C, COBOL, FORTRAN, FORTRAN??, and PL/L You cannot perform 
intralanguage binding for NEWP and Pascal programs. 

ALGOL Intralanguage Binding 

(In this section, any reference to ALGOL also refers to the extensions of ALGOL, 
such as BDMSALGOL, DCALGOL, and DMALGOL.) 

ALGOL intralanguage binding consists of binding one or more ALGOL procedures 
(or subprograms) into an ALGOL host program. The declaration of the 
subprogram must match its declaration in the host as to the type of subprogram, 
its number and type of parameters, and its execution level. 

Compiling ALGOL Host Programs and Subprogram 

An ALGOL host program can be either the outer block of an ALGOL program or 
an ALGOL procedure. 

An ALGOL subprogram compiled independently is called a separate procedure. 
To bind the procedure to a host program, you must compile the procedure at the 
same lexical level as that of the procedure within the host. Use the Binder control 
record option, LEVEL, described in Appendix B, to set the desired lexical level of 
the procedure you want to bind. If you do not set the LEVEL option, the lexical 
level of the procedure is 3. 

Parameter names declared in the procedure need not be the same as those 
declared in the host. If unmatched identifiers exist in the host and in the 
procedure you want to bind, declare a Binder USE statement to correct the 
mismatch. (For the syntax and explanation of the USE statement, see Section 3.) 

A separate procedure can reference any item declared in the host that is global to 
the lexical level of that procedure. This includes items at intermediate lexical 
levels. 

Any item declared after the body of a given procedure in a host program can be 
referenced by a separately compiled procedure that replaces the original 
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procedure. Thus, a host program that contains a separately compiled and bound 
procedure might produce different results from the same program fully compiled 
by the ALGOL compiler. 

Note: Binder can only repUicement bind DCALGOL exception and epilog 

procedures. Only one procedure, epilog or exception, can appear in a 
block. 

Declaring Global Items within an ALGOL Procedure 

You must declare all global items within the separate procedure that references 
them. This ensures that no undeclared global identifiers exist within the 
procedure. You can declare global items by using either the brackets method or 
the INFOJile method described later in this section. 

Using the Bracl(ets IVIethod 

With this method, you enclose global item declarations in brackets and place the 
declarations before the separate procedure. A bracketed set of global 
declarations, also known as the global part, is illustrated in the following 
example. 

[REAL S; 
ARRAY B [1]; 
FILE LINE; 

PROCEDURE PROC (V); VALUE V; 
REAL V; EXTERNAL;] 

When a compilation includes multiple procedures, you must include all global 
items referenced by all procedures within the same set of brackets and place the 
global part before the first procedure to be compiled. 

Following are some Binder exceptions to the typical way of declaring ALGOL 
items: 

• You can declare an array with lower bounds only. 

• You can declare switch items without declaring the corresponding switch list 

items. 

• Declaring a LABEL item as a new global item is illegal unless a "bad GO TO" 
to that label appears in the host. (A "bad GO TO" transfers control from an 
inner block to a label that is global to that block.) 

• If the same global array in the subprogram and host program are different 
sizes, and the host array is not an equivalence array, the array in the bound 
code file will be the larger of the two arrays. Arrays with lower bounds 
larger than 131,071 words remain unchanged. 

• If a global array in the subprogram is bound to an equivalence array in the 
host program, the array in the bound code file takes on the size of the array 
in the ALGOL host program. 
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Using the INFO Fiie IVIethod 

With this method of declaring global items, you store declared information for 
Binder in an INFO file. You can create an INFO file by placing the DUMPINFO 
compiler control record at any point within the symbolic file of the host program 
and compiling your ALGOL program with DUMPINFO set to TRUE. 

DUMPINFO places information about all items within the scope of the DUMPINFO 
control record into the INFO file. For example, if a DUMPINFO compiler control 
record is placed just before the last END statement of a program, all global items 
declared in that program are described in the INFO file. 

To recover the information about the declared items from the INFO file, include 
the LOADINFO compiler control record in the subprogram before the first 
procedure to be compiled. 

Note that INFO files created by the ALGOL compiler cannot be used by an 
ALGOL compiler of a different release level. For example, if an INFO file is 
created by the DUMPINFO compiler control option of the Mark 3.8 ALGOL 
compiler, the INFO file cannot be used by the LOADINFO compiler control option 
of the Mark 3.9 ALGOL compiler. If the release levels of the INFO files do not 
match, a syntax error message is given and the compilation is discontinued. 

For a description of INFO files and the DUMPINFO and LOADINFO compiler 
control options, refer to the ALGOL Reference Manual^ Volume 1. 

You can use a combination of the INFO file and brackets methods to add global 
items to the host without recompiling the host program. To do this, place the 
LOADINFO compiler control record within the brackets before the first global 
declaration. 



Adding New Global Items to an ALGOL Host Program 

If a subprogram references a global item not declared in the host program, Binder 
adds the item to the host as a new global item when binding the procedure into 
the host. Binder adds new global items at the global level of the host. 

The following rules apply when Binder adds new global items to a host program: 

• Binder cannot add the following variable types as new global items: 

- DMSII database 

- FORMAT 

- LABEL 

- LIBRARY 

- LIST 

- PICTURE 

- SDF form record libraries 
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- SIM databases 

- Switch items 

- Transaction base 

• Binder can add a new global array only if the array is declared in the 
subprogram with both upper bounds and lower bounds. 

• Binder strips a new global file of any specified file attributes during the 
binding process. Thus, you must indicate all necessary file attributes by using 
a file equation. Note that if a global file is already present in the host and is 
being replaced during the binding procedure, the file attributes specified in 
the host are used. 



Using the ALGOL Separate Compilation Facility 

The ALGOL compiler provides a separate compilation and binding facility called 
sepcomp. The sepcomp facility lets you easily recompile and bind procedures 
contained within one large symbolic file. When you make changes to a procedure, 
you can use the sepcomp facility to recompile only the changed procedure, rather 
than recompiling the entire program. 

To use the sepcomp facility, you must first create a host object code file by 
compiling the program with the ALGOL MAKEHOST compiler control option set 
to TRUE. This causes the ALGOL compiler to save special Binder information in 
the object code file. 

Next, make changes to your program in a patch file. The first record of the patch 
file must set the ALGOL SEPCOMP compiler control option to TRUE. This signals 
the compiler to perform a separate compilation. 

During the sepcomp process, the ALGOL compiler determines which procedures 
are affected by the patch file and recompiles those procedures. The compiler then 
invokes Binder to bind the recompiled procedures into the rest of the object code 
obtained from the host file. 

(Refer to the ALGOL Reference Manual^ Volume 1 for more information about the 
SEPCOMP and MAKEHOST options.) 

Library Binding in ALGOL 

You can bind libraries and library objects like other locally or globally declared 
nonprocedure items. You can declare exported procedures as EXTERNAL, and 
you can bind and replacement bind them. For more information about libraries 
and exported procedures, refer to the A Series System Software Utilities Manual 
and the ALGOL Programming Manualj Vohmie 1 . 

Libraries in subprograms do not have to be explicitly declared in the host 
program. If libraries are not declared in the host program, Binder builds a library 
template from the binding information in the subprogram file. Once the template 
is built, Binder can add library objects not explicitly declared in the host 
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program. When declaring libraries in the global part, you must declare the library 
before declaring the library object. 

The restrictions that apply to library binding are as follows: 

• Additional library objects can be added to a library declared in the host 
program if the host program was compiled with a Mark 3.8 compiler or a 
more recent version of the compiler. 

• Library attributes cannot be changed or added from a subprogram. The 
library attributes in the host are always used, so it is not necessary to include 
any attributes in the subprogram. 

• The declaration of a procedure to be bound to an exported procedure must be 
identical to the declaration of the exported procedure. 

• Library objects and by-calling procedures cannot be declared external and 
bound in. (A by-calling procedure is a procedure that is declared in a library 
program and is specified to be exported dynamically.) 

• By-calling procedures cannot be declared in the global part of a procedure 
that is to be bound to a host program. 

• If a new global library object is declared in two or more subprograms, then 
the global library objects must be identical and match the library object in the 
library referenced. 

Record Binding in ALGOL 

Binding of records retrieved from a data dictionary is allowed in ALGOL. 
However, Binder does not check the format of the records involved, nor does it 
make any distinction between records and EBCDIC arrays. Thus, Binder allows 
any record to be bound to any other record, and allows any record to be bound to 
any star-bounded EBCDIC array and vice versa. 

Example of ALGOL Intralanguage Binding 

The following example shows an ALGOL host program, a subprogram, and the 
Binder input file used to bind them together. The WFL job used to compile each 
program appears in italic type. 

ALGOL Host Program 

? BEGIN JOB ALGOL/HOST; 
COMPILE OBJECT/HOST ALGOL LIBRARY; 
ALGOL DATA 
BEGIN 

FILE LINE(KIND=PRINTER,MAXRECSIZE=22); 
ARRAY BUFFER [0:2, 0:8]; 
REAL J; 

PROCEDURE PRINTIT; EXTERNAL; 
FOR J := 0 STEP 1 UNTIL 8 DO 
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BUFFER[0,J] := BUFFER[1,J] :» BUFFER[2,J] := " "; 
FOR J := 0 STEP 1 UNTIL 2 DO 

BUFFER[J,1] := BUFFER [J, 3] BUFFER[J,5] := "*"; 
BUFFER[1,2] :="*••; 
PRINTIT; 
END. 
? END JOB. 

ALGOL Subprogram 

? BEGIN JOB COMPILE/PRINTIT; 
COMPILE OBJECT/PRINTIT ALGOL LIBRARY; 
ALGOL DATA 

[ARRAY BUFFER[0,0]; REAL J, K; FILE LINE;] 

PROCEDURE PRINTIT; 

BEGIN 

FOR J :» 0 STEP 1 UNTIL 2 DO 

WRITE ( LINE, <3A1, XI, 3A1>, FOR K := 1 STEP 1 UNTIL 6 

DO BUFFER[J,K]); 

END; 
? END JOB, 

Binder Input File 

? BEGIN JOB BIND/PRINTIT; 

BIND OBJECT/HELLO BINDER LIBRARY; 

BINDER DATA 

HOST IS OBJECT/HOST; 

BIND PRINTIT FROM OBJECT/PRINTIT; 

STOP; 
? END JOB. 



The result of the bind is a program entitled OBJECT/HELLO. When 
OBJECT/HELLO is executed, it produces the following output: 

* * * 

* * ★ 



Example of Binding an ALGOL Library 

This binding example includes an ALGOL library host program, an ALGOL 
subprogram to be bound to that library, and the Binder input file used to bind 
them together. The WFL job used to compile each program appears in italic type. 

ALGOL Host Program 

? BEGIN JOB COMPILE/LIB/HOST; 
COMPILE OBJECT/LIB/HOST ALGOL LIBRARY; 
ALGOL DATA 
BEGIN 
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PROCEDURE REVERSE (A,B,LEN); 
VALUE LEN; 

EBCDIC ARRAY A,B [0]; 

INTEGER LEN; 
BEGIN 
END; 

EXPORT REVERSE; 
FREEZE (TEMPORARY); 

END. 
7 END JOB. 

ALGOL Subprogram 

? BEGIN JOB COMPILE/REVERSE; 
COMPILE OBJECT/REVERSE ALGOL LIBRARY; 
ALGOL DATA 

PROCEDURE REVERSE (A.B.LEN); 
VALUE LEN; 

EBCDIC ARRAY A, B [0]; 
INTEGER LEN; 
BEGIN 

INTEGER J; 
IF LEN > 0 

AND LEN <= SIZE(A) AND LEN <= SIZE(B) 
THEN 

FOR J := 0 STEP 1 UNTIL (LEN-1) DO 
REPLACE B[J] BY A[LEN-J-1] FOR 1; 

END; 
? END JOB, 

Binder Input File 

? BEGIN JOB BIND/SYSTEM/MYLIB; 
BIND SYSTEM/MYLIB BINDER LIBRARY; 
BINDER DATA 

HOST IS OBJECT/LIB/HOST; 
BIND REVERSE FROM OBJECT/REVERSE; 
STOP; 
? END JOB. 

The result of the bind is a library named SYSTEM/MYLIB. This library is used in 
the following example. 

Example of Binding an ALGOL Program That References a Library 

This example shows an ALGOL host program, a subprogram, and the Binder input 
file used to bind them together. The WFL job used to compile each program 
appears in italic type. This example uses the library, SYSTEM/MYLIB, created in 
the preceding example. 



8600 0304-000 



4-7 



Binding Programs Written in the Same Language 



ALGOL Host 

? BEGIN JOB COMPILE/HOST; 
COMPILE OBJECT/HOST ALGOL LIBRARY; 
ALGOL DATA 
BEGIN 

LIBRARY L (LIBACCESS = BYTITLE, 

TITLE = "SYSTEM/MYLIB."); 
PROCEDURE REVERSE (A,B,LEN); 
VALUE LEN; 

EBCDIC ARRAY A,B [0]; 
INTEGER LEN; 
LIBRARY L; 

PROCEDURE P; EXTERNAL; 

P; 

END. 
? END JOB. 

ALGOL Subprogram 

? BEGIN JOB COMPILE/P; 
COMPILE OBJECT/P ALGOL LIBRARY; 
ALGOL DATA 

[LIBRARY L (LIBACCESS = BYTITLE, 

TITLE = "SYSTEM/MYLIB."); 
PROCEDURE REVERSE (A,B,LEN); 
VALUE LEN; 

EBCDIC ARRAY A,B [0]; 
INTEGER LEN; 
LIBRARY L; 

] 

PROCEDURE P; 
BEGIN 

EBCDIC ARRAY El, E2 [0:29]; 
FILE F (KIND = PRINTER); 

REPLACE E1[0] BY "ABCDEFGHIJKLMNOPQRSTUVWXYZ 
REPLACE E2[0] BY " " FOR 30; 
REVERSE (E1,E2,10); 
WRITE (F,5.E1); 
WRITE (F,5,E2); 

END; 
? END JOB. 

Binder Input File 

? BEGIN JOB BIND/P; 

BIND OBJECT/BOUND BINDER LIBRARY; 

BINDER DATA 

HOST IS OBJECT/HOST; 

BIND P FROM OBJECT/P; 

STOP; 
? END JOB. 
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The result of the bind is a file named OBJECT/BOUND. When executed, 
OBJECT/BOUND produces the following result: 

ABCDEFGHIJKLMNOPQRSTUVUXYZ 
JIHGFEDCBA 

C Intralanguage Binding 

C intralanguage binding involves binding a C function into a C host program. It is 
not possible to bind a C library; however, you can bind programs that reference 
libraries. C functions cannot be replacement bound. 

Compiling C Host Programs and Subprograms 

A C host program is a C program that contains the function, "main." The host 
program can contain variables and functions that are referenced by external 
functions. 

You cannot use a bound C program as a host program for a subsequent bind. 

If the host program appears in a BIND ? statement (see Section 3), it is not 
necessary to file equate the host program or use a HOST statement in the primary 
input file. 

A C subprogram file is any C code file that does not contain the function, "main." 
Unlike other programming languages, an explicit compiler control option (such as 
LEVEL or SEPARATE) is not required to create a subprogram file. 

Describing Functions and Variables 

Any function or variable not declared with the storage class specifier, static, is 
implicitly exported. 

All references to a variable or function must match the declaration of the 
variable or function in type, number, and types of parameters. 

Example of C Intralanguage Binding 

The following example shows a C host program, a C subprogram, and the Binder 
input file used to bind them together. The WFL job used to compile each program 
appears in italic type. 

C Host Program 

? BEGIN JOB C/MAIN; 
COMPILE C/MAIN CC LIBRARY; 
CC DATA 
#1nclude <std1o.h> 
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print_it (int s) { 

printf ("the sura is %i\n",s); 

> 

main () { 

int i » 12, j = 24; 
add (i, j); 

} 

? £ND JOB. 

C Subprogram 

? BEGIN JOB C/ADD; 
COMPILE C/ADD CC LIBRARY; 
CC DATA 
int add (int x, int y) { 
print_it (x + y) { 

} 

? END JOB. 
Binder Input File 

? BEGIN JOB C/BIND; 

BIND SUM BINDER; 

BINDER DATA 

BIND ? FROM C/ADD; 

BIND ? FROM C/MAIN; 
? END JOB. 

The result of the bind is a file named SUM. When executed, SUM produces the 
following output: 

the sum is 36 



COBOL Intralanguage Binding 

COBOL intralanguage binding consists of binding a COBOL subprogram into a 
COBOL host. The declaration of the subprogram must match its declaration in the 
host as to the type of subprogram, its number and type of parameters, and its 
execution level. 

Note: COBOL68, COBOL74, and C0B0L85 programs iisually are bound 

similarly and, therefore, are discussed in this section generically as 
COBOL programs. When a difference exists, the version is specified. 
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Compiling COBOL Host Programs and Subprograms 

A COBOL host program is a COBOL program compiled at the default lexical (lex) 
level of 2. 

You must compile subprograms at a lex level compatible with their usage in the 
host program. All subprograms must be compiled at one lex level higher than the 
lex level of the subprogram in which they are declared. For example, a 
subprogram to be bound to a lex level 3 subprogram must be compiled at lex 
level 4. 

If a subprogram is declared directly in the host, you must set the LEVEL option 
to 3 during the compilation of that subprogram. 

You must describe in the subprogram any parameters being passed to the 
subprogram from a host program. You must also specify such parameters 
following the keyword USING in the PROCEDURE DIVISION heading. You must 
declare parameters in the LOCAL-STORAGE (LD entry) of the DATA DIVISION 
and identify them as being passed by reference or by content. 

Binding an External Procedure to a COBOL Host Program 

To bind an external procedure to a COBOL host program, you must declare the 
procedure as external in the DECLARATIVES portion of the PROCEDURE 
DIVISION of the host program. 

You can indicate the title of the code file containing the subprogram by using the 
CODE FILE TITLE IS <mnemonic name> option within the SPECIAL-NAMES 
paragraph. Note that using a BIND statement overrides the SPECIAL-NAMES 
paragraph. 

Activating Bound Subprograms 

You can activate bound subprograms by using either the ENTER or CALL verb. 
Immediately following the verb, you must indicate the name of the section in the 
DECLARATIVES portion that contains the procedure description of the 
subprogram. Binder uses the section name that declares the subprogram as 
external to process the external subprogram. All Binder statements that pertain 
to an external subprogram must reference the corresponding section name. 

Global Declarations In Subprograms 

Any variable that can be passed or received as a parameter can be declared as a 
global variable in the subprogram. Untyped procedures, files, and direct files can 
also be declared as global variables in the subprogram. To declare global 
variables, use the GLOBAL clause. The following COBOL74 examples illustrate 
the declaration of global variables in the WORKING-STORAGE SECTION of the 
subprogram. 
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77 GLASTATUS GLOBAL BINARY PIC 9(11). 

77 BL-EVNT GLOBAL EVENT. 

77 GL-SWFL INDEX FILE GLOBAL. 

01 GL-RCD RECORD AREA GLOBAL OCCURS 10 PIC X(180) 

01 GL-EBCRAY GLOBAL. 

03 CMP-ITE BINARY PIC 9(11) 

OCCURS 100 INDEXED BY II. 

If most of the variables declared in the WORKING-STORAGE SECTION are global, 
use the GLOBAL compiler control option. You can set this option throughout the 
compilation. 

The GLOBAL option affects only the variables that are candidates for global 
declarations and only the items declared in the WORKING-STORAGE SECTION. 

You can use the LOCAL or OWN option to override the GLOBAL option. In the 
following example, items Gl, G2, and G3 are declared GLOBAL; I is declared 
OWN; and LI is declared LOCAL. 

$ SET GLOBAL 
77 Gl BINARY PIC 9(11). 

77 G2 BINARY PIC 9(11). 

77 LI LOCAL 

BINARY PIC 9(11). 

01 G3. 

03 FLD BINARY PIC 9(11) OCCURS 10 INDEXED BY I. 



OWN Declarations In the Subprogram 

COBOL programs compiled at lex level 3 or higher can declare certain variables 
as OWN in the subprogram. OWN variables retain their initial values or states 
throughout repeated exit and reentry of the subprogram in which they are 
declared. 

With the exception of direct switch files, you can declare any item in the 
WORKING-STORAGE SECTION of the subprogram as OWN by using either the 
OWN clause or the OWN compiler control option. 

All related index names for OWN items are also considered to be OWN. Redefined 
OWN items are implicitly OWN, so you do not need to specify them in the OWN 
clause. 

If you use the OWN compiler control option throughout the compilation, all 
variables declared in the WORKING-STORAGE SECTION are declared OWN, 
unless they are direct files. 

You can use the LOCAL or GLOBAL clause to override the OWN option for any 
individually specified item. 
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Library Binding in COBOL 

Binder lets you bind COBOL programs that are libraries and COBOL programs 
that reference libraries. You can bind libraries and library objects as you would 
other locally or globally declared nonprocedure items. 

To bind a COBOL library, declare the library as external in the host program and 
make sure that the procedure parameters match those in the host program. 

Libraries in subprograms do not have to be explicitly declared in the host 
program. If libraries are not declared in the host program, Binder builds a library 
template from the binding information in the subprogram file. Once the template 
is built, Binder can add library objects not explicitly declared in the host 
program. When declaring libraries in the global part, you must declare the library 
before declaring the library object. 

Exampie of COBOL Intraianguagie Binding 

The following example contains a COBOL host program and a subprogram, and 
the Binder input file used to bind them together. The WFL job used to compile 
each program appears in italic type. 



COBOL Host Program 



? BEGIN JOB COMPILE/HOST; 
COMPILE C0B0L74/H0ST C0B0L74 LIBRARY; 
C0B0L74 DATA 

IDENTIFICATION DIVISION. 

PROGRAM- ID. HOST. 

ENVIRONMENT DIVISION. 

CONFIGURATION SECTION. 

SOURCE- COMPUTER. A- 15. 

OBJECT-COMPUTER. A- 15. 

SPECIAL-NAMES. 

"COBOL- '/"PROG" IS TO-BE-CALLED. 

INPUT-OUTPUT SECTION. 

FILE-CONTROL. 

SELECT PR ASSIGN TO PRINTER. 

DATA DIVISION. 

FILE SECTION. 

FD PR. 

01 PR-RCD PIC X(36). 

WORKING-STORAGE SECTION. 

01 ORIG PIC X(36). 

01 NEW PIC X(36). 

LOCAL-STORAGE SECTION. 

LD PARMS. 

01 A PIC X(36) REF. 

01 B PIC X(36) REF. 

PROCEDURE DIVISION. 
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DECLARATIVES. 
SI SECTION. 

USE EXTERNAL TO-BE-CALLED AS PROCEDURE WITH FARMS USING A B. 
END DECURATIVES. 
THE-MAIN SECTION. 
START. 

OPEN OUTPUT PR. 

MOVE "THIS WILL STOP WHEN THIS LINE ENDS" TO GRIG. 
ENTER SI USING ORIG NEW. 
WRITE PR-RCD FROM ORIG. 
WRITE PR-RCD FROM NEW. 
STOP RUN. 

7 END JOB. 

COBOL Subprogram 

? BEGIN JOB COMPILE/PROG; 
COMPILE C0B0L74/PR0G C0B0L74 LIBRARY; 
C0B0L74 DATA 

$ SET LEVEL =3 

IDENTIFICATION DIVISION. 

PROGRAM- ID. ARRAY/MIXER. 

ENVIRONMENT DIVISION. 

CONFIGURATION SECTION. 

SOURCE-COMPUTER. A-9. 

OBJECT- COMPUTER. A-9. 

DATA DIVISION. 

WORKING-STORAGE SECTION. 

01 X REF. 



03 


ONE 


PIC 


X(5) 


03 


SECOND 


PIC 


x(5; 


03 THIRD 


PIC 


x(5; 


03 


FOURTH 


PIC 


x(5; 


03 


FIFTH 


PIC 


X(5) 


03 


SIXTH 


PIC 


x(5; 


03 


SEVENTH 


PIC 


x{5; 


03 


EIGHTH 


PIC 


X(l] 


REF. 






03 


FIRS 


PIC 


X(5] 


03 


SECON 


PIC 


x(5; 


03 THIR 


PIC 


x(5: 


03 


FOURT 


PIC 


x(5; 


03 


FIFT 


PIC 


X(5 


03 


SIXT 


PIC 


x(5; 


03 


SEVENT 


PIC 


X(5] 


03 


EIGHT 


PIC 


X(l] 



PROCEDURE DIVISION USING X Y. 
THE- SUBPROGRAM SECTION. 
MIX. 

MOVE ONE TO SECON. 
MOVE SECOND TO FOURT. 
MOVE THIRD TO FIRS. 
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MOVE FOURTH TO THIR. 
MOVE FIFTH TO SIXT. 
MOVE SIXTH TO SEVENT. 
MOVE SEVENTH TO FIFT. 
MOVE EIGHTH TO EIGHT. 

? END JOB. 
Binder Input File 

? BEGIN JOB BIND/RESULT; 

BIND C0B0L74/EXAMPLE BINDER; 

BINDER DATA; 

HOST IS C0B0L74/H0ST; 

USE SI FOR PROG; 

BIND SI FROM COB0L74/PR0G; 
? END JOB. 

The result of the bind is an object file titled COBOL74/EXAMPLE. When 
executed, the program generates the following output: 

THIS WILL STOP WHEN THIS LINE ENDS 
STOP THIS WHEN WILL ENDS THIS LINE 

FORTRAN Intralanguage Binding 

FORTRAN intralanguage binding consists of binding a FORTRAN subroutine or 
function into a FORTRAN host. 



Compiling FORTRAN Host Programs and Subprograms 

A FORTRAN host is a FORTRAN program that contains a main program. The host 
can also include subroutines or functions compiled with the main program. 

A FORTRAN subprogram is a FORTRAN subroutine or function. You must 
compile the subprogram at a lexical (lex) level consistent with its lex level within 
the host. 

Any subprogram bound into a host must match its invocations in the host 
program in terms of the number and type of parameters. If the subprogram 
identifier does not match its invocation as specified in the host, you must use the 
Binder USE statement to correct the mismatch. 

If an entry point is referenced by a host program, but the corresponding 
subprogram is not referenced, you must use a BIND statement to specify the file 
in which the entry point is located. 
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FORTRAN Common Blocks 

When a common block is bound, its resulting length is the largest of all the length 
values declared for that common block in the host and bound subprograms. 

Library Binding in FORTRAN 

Subroutines and functions can be bound or replacement bound into a host 
program that references libraries. 

Libraries in subprograms do not have to be explicitly declared in the host 
program. If libraries are not declared in the host program, Binder builds a library 
template from the binding information in the subprogram file. Once the template 
is built, Binder can add library objects not explicitly declared in the host 
program. 

Exported subroutines and functions can be replacement bound. You cannot add 
new exported program units to a host. 

You can bind program units that do not reference libraries into host programs 
that are libraries or that reference libraries. 

Example of FORTRAN Intralanguage Binding 

The following example shows a FORTRAN host program and subprogram, and the 
Binder input file used to bind them together. The WFL job used to compile each 
program appears in italic type. 

FORTRAN Host Program 

? BEGIN JOB COMPILE/HOST; 

COMPILE FORTRAN/HOST FORTRAN LIBRARY; 

FORTRAN DATA 

DIMENSION ICK(5,55) 

DO 5 1=1,5 

DO 5 0=1,55 
5 ICK(I,J)=" " 

DO 10 1-1,55 
10 CALL PLOT(ICK,I) 

DO 20 1=1,5 
20 WRITE(6,100) (ICK(I,J),0-1,55) 
100 FORMAT ( IX, 55A1) 

CALL EXIT 

END 

? END JOB. 
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FORTRAN Subprogram 

? BEGIN JOB COMPILE/PLOT; 

COMPILE FORTRAN/PLOT FORTRAN LIBRARY; 

FORTRAN DATA 
$ SET SEPARATE 

SUBROUTINE PLOT(ICK,I) 

DIMENSION ICK(5,55) 

ICK(3-SIN(I*0.3)*2,I)="*" 

RETURN 

END 

? END JOB. 
Binder Input File 

? BEGIN JOB BIND/PLOT; 

BIND SINE BINDER; 

BINDER DATA 

HOST IS FORTRAN/HOST; 
? END JOB. 

The result of the bind is an object file titled SINE. When executed, this program 
produces the following output: 

******* ******* ******* 

* ** ** ** ** ** 

** * ** * ** 

******* ******* * 

F0RTRAN77 Intralanguage Binding 

FORTRAN?? intralanguage binding consists of binding a FORTRAN?? 
subprogram into a FORTRAN?? host. 

Compiling F0RTRAN77 Host Programs and Subprograms 

A FORTRAN?? host is a program that has the BINDINFO compiler control option 
set. If a main program does not exist in the host program, the main program is 

assumed to be external. A FORTRAN?? host is compiled at an outer lexical (lex) 
level of 2. The main program is compiled at a lex level of 3. 

A FORTRAN?? subprogram can be a FORTRAN?? main program, subroutine, 
function, or block data subprogram. Each subprogram is compiled at a lex level 
of 3. 

Any subprogram bound into a host must match its invocations in the host in 
terms of number and type of parameters. If the subprogram identifier does not 
match its invocation as specified in the host, you must declare a Binder USE 
statement to correct the mismatch. 
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In cases where an entry point is referenced by a host but the corresponding outer 
subprogram is not referenced, you must use a BIND statement to specify the code 
file in which the ENTRY statement is located. 

A FORTRAN?? main program can be replaced by another FORTRAN?? main 
program or a FORTRAN?? subroutine that has no parameters. 

Files 

At execution time, file declarations in the host apply to all subprograms that are 
bound into the host. If a new file is bound into the host, the first declaration for 
the new file encountered during binding takes precedence over other declarations. 

Common Blocks 

When a common block is bound, its resulting length is the largest of all the length 
values declared for that common block in the host and subprograms, as long as 
the compiler control option CODEFILEINIT is not set in the host. Any common 
block that has been initialized in the code file cannot be extended. 

Library Binding In FORTRAN?? 

You can replacement bind exported subroutines and functions into a FORTRAN?? 
host program that is a library. You cannot add or delete exported subprograms 
from a host program. 

Libraries in subprograms do not have to be explicitly declared in the host 
program. If libraries are not declared in the host program. Binder builds a library 
template from the binding information in the subprogram file. Once the template 
is built. Binder can add library objects not explicitly declared in the host 
program. When declaring libraries in the global part, you must declare the library 
before declaring the library object. 

If you compile a program with the SEPARATE option set, you must declare all 

libraries and entities imported from those libraries before the first executable 
program unit. Each program unit can contain references only to those libraries 
and library objects that it uses. 

Example of FORTRAN?? Intralanguage Binding 

The following example shows the binding process involved in binding three 
FORTRAN?? subprograms to a FORTRAN?? host program. 

First, the skeleton library program is created and compiled as a Binder host 
during a Command and Edit (CANDE) session. 
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File Name: BOUND/LIB/HOST 

$ SET BINDINFO 

BLOCK GLOBALS 

EXPORT (PASSR, PASSI, EQV) 

END 

SUBROUTINE PASSR (R) 
REAL R 

END 

SUBROUTINE PASSI (I) 
INTEGER I 

END 

LOGICAL FUNCTION EQV (Rl, R2) 
REAL Rl. R2 

END 

CALL FREEZE ('TEMPORARY') 
END 

Next, the following three separate subprograms are compiled: 

FUe Name: BOUND/LIB/PASSR 

$ SET SEPARATE 

SUBROUTINE PASSR (R) 
REAL R 

PRINT *, ' IN PASSR, R = ', R 

END 

FUe Name: BOUND/UB/PASSI 

$ SET SEPARATE CALLBYREFERENCE 
SUBROUTINE PASSI (I) 
INTEGER I 

PRINT *, • IN PASSI, I (ROUNDED) = ', I 

END 

FUe Name: BOUND/LIB/EQV 

$ SET SEPARATE 

LOGICAL FUNCTION EQV (Rl, R2) 

PARAMETER (TINYNO - 0.000000001) 
REAL Rl, R2 

EQV » ( ABS(R1 - R2) .LT. TINYNO ) 

END 

The following Binder input file is used to bind the three separate code files into 
the library program: 

FUe Name: BOUND/LIB 

HOST IS OBJECT/BOUND/LIB/HOST; 

BIND PASSR FROM OBJECT/BOUND/LI B/PASSR; 
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BIND PASSI FROM OBJECT/BOUND/LIB/PASSI ; 
BIND EQV FROM OBJECT/BOUND/LIB/EQV; 

The following program references the newly bound library: 

FUe Name: REF/BOUND/LIB 

BLOCK GLOBALS 

LIBRARY LIB (TITLE*' OBJECT/BOUND/LIB ' ) 

END 

SUBROUTINE PASSR (R) 
REAL R 

IN LIBRARY LIB 

END 

SUBROUTINE PASSI (I) 
INTEGER I 
IN LIBRARY LIB 

END 

LOGICAL FUNCTION EQV (Rl, R2) 
REAL Rl, R2 
IN LIBRARY LIB 

END 

LOGICAL EQV 

X = 1.7 

Y = 1.7 

CALL PASSR (X) 

CALL PASSI (Y) 

IF ( EQV(X, Y) ) THEN 

PRINT *, ' X STILL EQUALS Y' 
ELSE 

PRINT *, • X NO LONGER EQUALS Y' 
END IF 
END 

When executed, the preceding program produces the following output: 

IN PASSR, R » 1.7 

IN PASSI, I (ROUNDED) = 2 

X STILL EQUALS Y 

Usually, when a FORTRAN?? variable or array element appears as an actual 
argument (that is, the corresponding dummy argument is a variable), the 
argument is passed by vcdue-resuU, The dummy argument is assigned the value of 
the actual argument when the subprogram is entered. If the value of the dummy 
argument changes, the final value of the dummy argument is assigned to the 
corresponding actual argument when execution of the subprogram is completed. 
Passing by value-result is also known as copy-restore. 

Note that in the preceding example, the compiler control option 
CALLBYREFERENCE is set for PASSI. Therefore, the argument to that 
subroutine is passed by reference riather than by value-result. Thus, the value of 
Y is not truncated when Y is passed to an integer. 
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Suppose that a new version of PASSI, called PASSI2, is created without 
CALLBYREFERENCE set. 

File Name: BOUND/LIB/PASSI2 

$ SET SEPARATE 

SUBROUTINE PASSI2 (I) 
INTEGER I 

PRINT *, ' IN PASSI2, I (ROUNDED) = ' . I 

END 

A new version of BOUND/LIB binds the new subroutine into the old library. 

File Name: BOUND/LIB 

HOST IS OBJECT/BOUND/LIB; 

BIND PASSI FROM 0BJECT/B0UND/LIB/PASSI2; 

USE PASSI FOR PASSI2; 

When REF/BOUND/LIB is executed again, the argument to PASSI2 is explicitly 
truncated to form an integer when the subroutine is entered. The following 
output is produced: 

IN PASSR, R = 1.7 

IN PASSI2, I (ROUNDED) = 1 

X NO LONGER EQUALS Y 

PL/I Intralanguage Binding 

PL/I intralanguage binding consists of binding one or more PL/I subprograms or 
procedures to a PL/I host. Communication among the procedures is performed 
through common EXTERNAL declarations within the procedures and through 
parameters; 

Declaring Host Programs and Subprograms 

You can declare any external PL/I procedure as a host program if the only 
parameters declared within the external procedure are CHARACTER VARYING 
or DECIMAL FIXED. 

Any external procedure not specified as the host is considered to be a 
subprogram. No parameter type restrictions exist for subprograms. 

STATIC EXTERNAL Variables 

If you declare a STATIC EXTERNAL variable in both the host program and the 
external procedure, the variable retains the value declared in the host upon 
binding. If you declare a STATIC EXTERNAL variable only in the external 
procedure, the variable retains the value declared in the external procedure. 
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If you declare a STATIC EXTERNAL variable in more than one external 
procedure but not in the host, a binding error occurs. 

Examples of declaring STATIC EXTERNAL variables in a host and in an external 
procedure are provided in the following example: 

HOSTrPROC; 

DCL A(4) FIXED STATIC EXTERNAL 
INIT (1.2.3,4), 
SEPARATE ENTRY EXTERNAL; 
CALL SEPARATE ( ); 
PUT DATA (A); 
END HOST; 
SEPARATE: PROC; 

DCL A(4) FIXED STATIC EXTERNAL INIT(5,6,7,8) , 

Al(4) FIXED STATIC EXTERNAL INIT(9,10,11,12) ; 
PUT DATA (A.Al); 
END SEPARATE; 

When executed, the bound code file produces the following output: 

A(l)= 1 A(2)= 2 A(3)= 3 A(4)= 4 Al(l)= 9 
Al(2)» 10 Al(3)= 11 Al(4)« 12 ; A(l)» 1 

A(2)= 2 A(3)= 3 A(4)= 4 ; 

You must initialize any STATIC EXTERNAL CONTROLLED or STATIC 
EXTERNAL BASED variable before using either variable in a declaration. For 
example, the first set of code below must be rearranged to initialize and declare 
the variables in the proper order, as shown in the second set of code. 

DCL 

1 S1{X) STATIC. 

2 A(X) INIT(B(1).B(2),B(3),B(4)), 
1 S2 STATIC, 

2 B{2*X) INIT(C(1).C(2),C(3),C(4)). 
1 S3 STATIC. 

2 C(2*X) INIT(1,2,3,4), 
X STATIC INIT(2); 



DCL 

X STATIC INIT(2), 
1 S3 STATIC, 

2 C(2*X) INIT(1,2,3,4), 
1 S2 STATIC, 

2 B(2*X) INIT(C(1).C(2).C(3),C(4)), 
1 S1(X) STATIC. 

2 A(X) INIT (B(1),B(2),B(3),B(4)); 

Variables whose order of declaration causes a program to run incorrectly when 
bound also cause a level 3 error at compilation time. 
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Example of PL/I Intralanguage Binding 

The following example shows a PL/I host program and subprogram, and the 
Binder input file used to bind them together. The WFL job used to compile each 
program appears in italic type. 

PL/I Host Program 

? BEGIN JOB COMPILE/HOST; 

COMPILE HOST/HOST PL/I LIBRARY; 

PL/ I DATA 
HOSTrPROC; 

DCL SEPARATE ENTRY (CHAR(*)) EXTERNAL; 

DCL CHR CHAR(8) INIT( 'ABCDEFGH' ) ; 

PUT SKIP LIST (CHR) ; 

CALL SEPARATE(SUBSTR(CHR.1.3)); 
END HOST; 
? END JOB. 

PL/I Subprogram 

? BEGIN JOB COMPILE/SEPARATE; 

COMPILE SEPARATE/SEPARATE PL/I LIBRARY; 
PL/ I DATA 
SEPARATE :PROC(C); 
DCL C CHAR(*); 
PUT SKIP LIST(C); 
END SEPARATE; 
? END JOB. 

Binder Input File 

? BEGIN JOB BIND/SEPARATE; 

BIND BOUND BINDER LIBRARY; 
BINDER DATA 
HOST IS HOST/HOST; 

BIND SEPARATE FROM SEPARATE/SEPARATE; 
STOP; 
? END JOB. 

When executed, the code file, BOUND, produces the following output in the 
SYSPRINT print file: 

ABCDEFGH 
ABC 



86000304-000 



4-23 



J 



Section 5 

Binding Programs Written in Different 
Languages 



The process of binding one or more subprograms and a host program written in 
different languages is known as interlangiiage binding. This section provides 
information about binding all of the allowable language combinations: 

ALGOL-COBOL COBOL-FORTRAN 
ALGOL-FORTRAN COBOL-FORTRAN?? 
ALGOL-FORTRAN?? COBOL-Pascal 
ALGOL-NEWP FORTRAN-FORTRAN?? 
ALGOL-Pascal 

Table 5-1 shows the allowable binding combinations. 



Table 5-1. Allowable Binding Combinations 



Subprogram 
Language 


Host Program Language 


ALGOL^ 


0 


COBOL 


FORTRAN 


FORTRAN?? 


NEWP* 


Pascal^ 


PL/i 


ALGOLS 


Yes 




Yes 


Yes 


Yes 


Yes 


Yes 




C 




Yes 














COBOL 


Yes 




Yes 


Yes 


Yes 




Yes 




FORTRAN 


Yes 




Yes 


Yes 


Yes 








FORTRAN?? 


Yes 




Yes 


Yes 


Yes 








PL/I 
















Yes 



^ All references to ALGOL Include the various extensions of ALGOL, such as BDMSALGOL, OCALGOL. and 
DMALGOL 



The NEWP Master Control Program (MCP) can serve only as a host program in binding. 
Pascal programs can serve only as host programs in binding. 
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ALGOL-COBOL Interlanguage Binding 

ALGOL-COBOL interlanguage binding consists of binding either an ALGOL 
subprogram into a COBOL host program or a COBOL subprogram into an ALGOL 
host program. 

Table 5-2 matches identifier types between ALGOL and COBOL. 



Table 5-2. Corresponding Identifier Types between ALGOL and COBOL 



ALGOL 


COBOL 


COBOL74 


REAL ARRAY 


COMP OCCURS 


REAL OCCURS 


INTEGER ARRAY 


COMP OCCURS 


BINARY OCCURS 


BOOLEAN ARRAY 


COMP OCCURS 


BINARY OCCURS 


DOUBLE ARRAY 






COMPLEX ARRAY 






HEX ARRAY 


COMP-2 




ASCII ARRAY 


ASCII 




EBCDIC ARRAY 


DISPLAY 


DISPLAY 


EBCDIC ARRAY [*] + 
INTEGER 


DISPLAY LOWERBOUNDS 
+ LEVEL 77 


DISPUY LOWER BOUNDS 
+ LEVEL 77 


REAL VARIABLE 


COMP-4 


REAL 


INTEGER VARIABLE 


COMP or COMP-1 


BINARY (1 to 11 digits) 


BOOLEAN VARIABLE 


COMP or COMP-1 


BINARY (1 to 11 digits) 


DOUBLE VARIABLE 


COMP-5 


DOUBLE 


COMPLEX VARIABLE 






UNTYPED PROCEDURE 


SECTION 


SECTION 


TYPED PROCEDURE 






UNTYPED PROCEDURE + 
2 PARAMETERS (EBCDIC 
ARRAY [•] + INTEGER) 


SECTION + 2 
PARAMETERS (DISPLAY 
LOWERBOUNDS + LEVEL 
77) 


SECTION + 2 
PARAMETERS (DISPLAY 
LOWERBOUNDS + LEVEL 

77) 


FILE 


FILE 


FILE 


DIRECT FILE 


DIRECT FILE 


DIRECT FILE 
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Global Items 

Global items can be shared between COBOL and ALGOL programs. If a COBOL 
subprogram references a global variable in an ALGOL host program, you must 
declare the variable in COBOL by using the GLOBAL clause or by setting the 
GLOBAL compiler control option in the COBOL subprogram to TRUE. 

Similarly, when an ALGOL subprogram references a global variable in a COBOL 
host program, you must declare the variable in ALGOL by using either the 
brackets method or the INFO file method described in Section 4. 



Parameters 

You must observe the following requirements when passing parameters between 
ALGOL and COBOL: 

• If the ALGOL host program passes arrays to or receives arrays from COBOL 
subprograms, you must declare the arrays in the ALGOL host program with a 
lower bound of zero. 

• When a word-oriented (integer, real, or Boolean) array or variable is passed 
between ALGOL and COBOL68, you must declare the word-oriented entity as 
COMPUTATIONAL in the COBOL68 program. 

In a COBOL74 program, you must declare a real array or variable as REAL, 
and an integer or Boolean array or variable as BINARY. 

• ALGOL EBCDIC arrays correspond to COBOL DISPLAY items. 

• You can pass files and direct files between ALGOL and COBOL. 

• If a file is declared to have a file record in COBOL, the ALGOL program must 
declare the file or direct file followed by a by-vabie pointer to match the file 
record. 

• You cannot pass a procedure as a parameter between ALGOL and COBOL. 

• Binder allows a procedure with unknown parameters to match and bind with 
a procedure of the same name with either known or unknown parameters. 

Libraries 

You do not need to declare attributes for a global library in a procedure to be 
bound. Instead, Binder uses the attributes found in the host program. 

Record Binding 

You can bind records retrieved from a data dictionary. However, Binder does not 
check the format of the records involved, nor does it make any distinction 
between records and EBCDIC arrays. Thus, Binder allows any record to be bound 
to any other record, and allows any record to be bound to any star-bounded 
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EBCDIC array and vice versa. Specifically, this means that you can bind an' 
ALGOL record to a COBOL EBCDIC array. 



Binding ALGOL and C0B0L74 Programs That Use COMS 

ALGOL and COBOL74 use different titles for the COMS support library. ALGOL 
names the library COMSSUPPORT, while COBOL74 names the library 
DCILIBRARY. 

To prevent library mismatch errors when binding a COBOL74 subprogram to an 
ALGOL host program, add the following Binder statement to the Binder input file: 

USE COMSSUPPORT FOR DCILIBRARY 

When binding an ALGOL subprogram to a COBOL74 host program, add the 
following Binder statement to the Binder input file: 

USE DCILIBRARY FOR COMSSUPPORT 

If you are using COMS service functions, you can avoid possible binding problems 
by using a naming convention for the library in the COBOL74 subprogram similar 
to that used in the ALGOL host program. Thus, use an internal name other than 
DCILIBRARY for the library in which the service functions reside and give the 
library the function name of COMSSUPPORT, as shown in the following example. 

Examples 

The following is an example of declaring a COMS service function in ALGOL. For 
more information on the declaration and use of COMS service functions, see the 
ALGOL Reference Mamud, Volume 2. 

LIBRARY SERVICE-LIB 

(FUNCTIONNAME » "COMSSUPPORT", LIBPARAMETER - "02"); 

INTEGER PROCEDURE GET.NAME.USING.OESIGNATOR 
(ENTY_DESIGNATOR, ENTY_NAME); 

REAL ENTY_DESIGNATOR; 

EBCDIC ARRAY ENTY-NAME[0] ; 
LIBRARY SERVICE.LIB; 



The following is an example of declaring a COMS service function in COBOL74. 
For more information on the declaration and use of COMS service functions, see 
the COBOL ANSI-74 Reference Mamud, Volume 2. 

CHANGE ATTRIBUTE LIBACCESS OF "SERVICE.LIB" 

TO BYFUNCTION. 
CHANGE ATTRIBUTE FUNCTIONNAME OF "SERVICE-LIB" 

TO COMSSUPPORT. 

CALL "GET-NAME-USING-DESIGNATOR OF SERVICE-LIB" 
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USING WS_DESG, 
WS-NAME 
GIVING SF-RSLT. 

ALGOL-FORTRAN Interlanguage Binding 

ALGOL-FORTRAN interlanguage binding consists of binding either an ALGOL 
subprogram into a FORTRAN host program or a FORTRAN subprogram into an 
ALGOL host program. 

Table 5-3 matches the identifier types between ALGOL and FORTRAN. 



Table 5-3. Corresponding Identifier Types between ALGOL and FORTRAN 



ALGOL 


FORTRAN 


REAL ARRAY 


REAL ARRAY/COMMON BLOCK 


INTEGER ARRAY 


INTEGER ARRAY/COMMON BLOCK 


BOOLEAN ARRAY 


LOGICAL ARRAY/COMMON BLOCK 


DOUBLE ARRAY 


DOUBLE PRECISION ARRAY/COMMON 
BLOCK 


COMPLEX ARRAY 


COMPLEX ARRAY/COMMON BLOCK 


HEX ARRAY 




ASCIIARRAY 




EBCDIC ARRAY 




EBCDIC ARRAY [*] + INTEGER 




REAL VARIABLE 


REAL VARIABLE 


INTEGER VARIABLE 


INTEGER VARIABLE 


BOOLEAN VARIABLE 


LOGICAL VARIABLE 


DOUBLE VARIABLE 


DOUBLE PRECISION VARIABLE 


COMPLEX VARIABLE 


COMPLEX VARIABLE 


UNTYPED PROCEDURE 


SUBROUTINE 


TYPED PROCEDURE 


FUNCTION 


UNTYPED PROCEDURE + 2 PARAMETERS 
(EBCDIC ARRAY [*] + INTEGER) 




FILE 


FILE 


DIRECT FILE 
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Parameters 

When ALGOL and FORTRAN program units are bound, only simple variables, 
arrays, and labels can be passed as parameters between program units. 
Procedures, functions, and subroutines cannot be passed as parameters between 
ALGOL and FORTRAN. 

Binder allows a procedure with unknown parameters to match and bind with a 
procedure of the same name with either known or unknown parameters. 

When simple variables and arrays are passed as parameters, the following special 
conditions apply: 

• All FORTRAN arrays are implemented as one-dimensional arrays. Thus, only 
one-dimensional ALGOL arrays (or array rows) can be passed between 
ALGOL and FORTRAN program units. 

• When passing an ALGOL array to a FORTRAN routine, you must declare the 
ALGOL array with a lower bound of 0 (zero). The ALGOL subscript 0 (zero) 
corresponds to the FORTRAN array's lower bound, usually 1. 

• When passing a FORTRAN array to an ALGOL routine, you must declare the 
ALGOL array with an asterisk (*) for the lower bound. If you use a FORTRAN 
subscript value to evaluate the parameter, the FORTRAN subscript 
corresponds to an ALGOL subscript value of 0 (zero). If you do not specify a 
subscript, the lower bound of the FORTRAN array (usually 1) is used. 

ALGOL describes all simple variable arguments to imported subprograms as 
call-by-name. FORTRAN describes them as call-by-reference. When calling a 
library object. Binder allows call-by-reference and call-by-name arguments to 
match at run time, 

• When passing simple variables between FORTRAN and ALGOL, you can mix 
by-name and by-value parameters. Note, however, that FORTRAN by-value 
parameters are different from ALGrOL by-value parameters. Thus the 
following conditions apply: 

- If FORTRAN calls an ALGOL procedure and passes a variable as a 
parameter, the variable acts like an ALGOL by-name parameter in all 
situations. 

- If FORTRAN calls an ALGOL procedure and passes an expression as a 
parameter, the expression acts like an ALGOL by-value parameter in all 
situations. 

- If ALGOL calls a FORTRAN program unit and passes a by-name 
parameter to a by-value formal parameter, the parameter acts like a 
FORTRAN by-value parameter. 

- If ALGrOL calls a FORTRAN program unit and passes a by-value 
parameter, the parameter acts like an ALGOL by-value parameter in all 
situations. 
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Global Items 

The only global items that can be shared between ALGOL and FORTRAN 
programs are files, subprograms, and common blocks matched to ALGOL arrays. 
No restrictions are imposed on the referencing of subprograms between the two 
languages. 

Files 

An ALGOL file with a declared internal name of FILEnn, where nn is a 1 -digit or 
2-digit number from 1 to 99 (without a leading zero), is identified as the same file 
as a FORTRAN file with that number. Thus, an ALGOL file declaration of FILE6 
and a FORTRAN subprogram file statement of WRITE (6,1) refer to the same file. 

This also applies to the use of ALGOL files as variable files within a FORTRAN 
program. For example, assume that an ALGOL host program declares a global file 
as FILE12 and declares a FORTRAN subprogram with the following statements: 

IX=12 

READ(IX.7)Y 

With these statements, the FORTRAN subprogram is bound into the ALGOL host 
program, and then the ALGOL global file is read. 

Note: The ALGOL print routine performs its carriage control after writing to a 
printer file. The FORTRAN print routine performs carriage control 
before vrriting to a printer file. To prevent potential printing problems, 
set the WRITEAFTER compiler control option when the ALGOL program 
is compiled. 

Common Blocks 

A FORTRAN common block is a one-dimensional, single-precision array 
immediately followed by a double-precision copy descriptor. The copy descriptor 
allows the same data items to be referenced from the single-precision array. 

An ALGOL subprogram can access a common block in a FORTRAN host program 
as a single-precision array, a double-precision array, or both. A common block in 
a FORTRAN subprogram can access ALGOL single- or double-precision arrays. 

When equating ALGOL arrays and FORTRAN common blocks, you must declare 
the arrays as global. 

You must enclose common block names in slashes (/), as in the following example: 
/ABC/ 



8600 0304-000 



5-7 



Binding Programs Written in Different Languages 



To indicate a blank common block, use the following syntax: 
/.BLNK./ 

A FORTRAN common block in a subprogram cannot contain an initial value when 
bound into an ALGOL host airay. However, an ALGOL array can be bound to a 
host common block that contains initial values. 

If a FORTRAN common block is equated to an ALGOL host array of a different 
length, the resulting array in the bound code file will be the longer of the two 
lengths. However, if the ALGOL array is an equivalence array, the resulting 
common block will be the size of the array that the equivalence array references. 

(Note that an equivalence array is an array that is declared to refer to the same 
data as another array.) 

Array B in the following example is an equivalence array: 

ARRAY A[0:99]; 
ARRAY B[l] = A; 

Simulating Common Bioclcs in ALGOL 

You can determine the contents of a FORTRAN common block by mapping the 
elements of the common declaration onto a contiguous array. You can simulate 
this procedure in ALGOL as shown in the following example: 

FORTRAN Statements 



DOUBLE PRECISION DA(IO) 
COMMON /C/ RA(7),X,DA 

ALGOL Statements 

ARRAY C[0:27]; 

DOUBLE ARRAY D[0] » C; 

DEFINE DA(N) = D[(N)+3] #, 

RA(N) = C[(N)-1] #, 

X = C[7] #; 

In this example, subscripts are adjusted so that DA(N) and RA(N) in the ALGOL 
code reference DA(10) and RA(7) in the FORTRAN common block. 



Accessing FORTRAN Common Blocks as ALGOL Arrays 

The following paragraphs describe how an ALGOL subprogram can access a 
FORTRAN common block as a single-precision array, a double-precision array, or 
as both. 
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Single-Precision Array 

To access a FORTRAN common block as a single-precision array, declare a global 
ALGOL array and equate it to the FORTRAN common block by using the Binder 
USE statement. For example, the USE statement for a single-precision ALGOL 
arrays and a FORTRAN host common block /BLK/ is as follows: 

USE /BLK/ FOR A; 

Double-Precision Array 

To access a FORTRAN common block as a double-precision array, declare the 
ALGOL array as double-precision, and then use the USE statement as shown in 
the previous example for a single-precision array. 

Single- and Double-Precision Arrays 

To access a FORTRAN common block as both single-precision and 
double-precision ALGOL arrays, declare both types of ALGOL array and equate 
the arrays to the FORTRAN common block by using a Binder USE statement. 

For example, with a single-precision ALGOL array A, a double-precision ALGOL 
array D, and a FORTRAN host common block /BLK/, the Binder USE statement is 
as follows: 

USE /BLK/ FOR A,D; 

If the common block and all of the global ALGOL arrays equated to it are of 
different lengths, the length of the resulting common block will be the longest of 
all of the lengths. If one of the ALGOL arrays is an equivalence array, the 
resulting common block will be the size of the array that the equivalence array 
references. 



Accessing ALGOL Global Arrays from a FORTRAN Common Block 

The following paragraphs describes how a common block in a FORTRAN 
subprogram can access single- and double-precision arrays in an ALGOL host 
program. 

Sin^e-Precision Array 

To access an ALGOL single-precision array through a FORTRAN common block, 
equate the array to the common block with a Binder USE statement. For example, 
given an ALGOL single-precision array A and a FORTRAN common block /BLK/, 
the Binder USE statement is as follows: 

USE A FOR /BLK/; 

Double-Precision Array 

To access an ALGOL double-precision array through a FORTRAN common block, 
you must perform the following steps: 
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• Declare the double-precision array immediately following the declaration of 
the single-precision array and equate the double-precision array to the 
single-precision array by using the equal sign 

• Equate the single-precision array to the FORTRAN common block by using a 
Binder USE statement. 

For example, to access an ALGOL single-precision array A and an ALGOL 
double-precision array D through a FORTRAN common block /BLK/, you 
would declare the ALisOL arrays in the ALGOL host program as follows: 

REAL ARRAY A [0:99]; 
DOUBLE ARRAY D[0]-A; 

Then you would use the following Binder USE statement: 
USE A FOR /BLK/; 

FORTRAN references to single-precision items in /BLK/ are changed by Binder to 
refer to array A, and FORTRAN references to double-precision or complex items 
in /BLK/ are changed to refer to array D. It is not sufficient for array D to be a 
copy of array A; array D must also be declared immediately following array A. 

Example of ALGOL-FORTRAN Binding 

The following example illustrates the binding of ALGOL and FORTRAN 
subprograms into a FORTRAN host program. The WFL job used to compile each 
program appears in italic type. 

FORTRAN Host Program 

1 BEGIN JOB COMPILE/HOST; 

COMPILE FORT/HOST FORTRAN LIBRARY; 
FORTRAN DATA 
DIMENSION X(l), Y(l) 
X(l) - "MENTAT" 
Y(l) = "RESDED" 
WRITE (6,1) X.Y 
1 FORMAT (2(X,A6)) 
CALL SUB (X,Y) 
WRITE (6.1) X,Y 
CALL SUBA (X,Y) 
WRITE (6.1) X.Y 
STOP 
END 

? END JOB. 

ALGOL Subprogram 

? BEGIN JOB COMPILE/FTEST/ALGOL; 

COMPILE FTEST/ALGOL ALGOL LIBRARY; 
ALGOL DATA 
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PROCEDURE SUBA(A,B); ARRAY A»B[*]; 
BEGIN 
REAL C; 

C := A[0]; 

REPLACE POINTER (A) BY B[0] FOR 3; 
REPUCE POINTER (B) BY C FOR 3; 
END; 
? END JOB. 

FORTRAN Subprogram 

? BEGIN JOB COMPILE/FTEST/FORTRAN; 

COMPILE FTEST/FORTRAN FORTRAN LIBRARY; 

FORTRAN DATA 
$ SET SEPARATE 

SUBROUTINE SUB(A,B) 

DIMENSION A(l), B(l) 

C-A(l) 

A(l) - B(l) 

B(l) - C 

RETURN 

END 

? END JOB. 
Binder Input File 

? BEGIN JOB BIND/ROUND/PROGM; 

BIND ROUND/PROGM BINDER; 

BINDER DATA 

HOST IS FORT/HOST; 

BIND - FROM FTEST/=; 
? END JOB. 

The result of the bind is a program titled, ROUND/PROGM. The execution of 
ROUND/PROGM generates the following output: 

MENTAT RESDED 
RESDED MENTAT 
MENDED RESTAT 



ALG0L-F0RTRAN77 Interlanguage Binding 

ALGOL-FORTRAN?? interlanguage binding consists of binding either an ALGOL 
subprogram into a FORTRAN?? host program or a FORTRAN?? subprogram into 
an ALGOL host program. 

You cannot bind a FORTRAN?? subroutine with a label parameter into an ALGOL 
host program. 
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Table 5-4 matches identifier types between ALGOL and FORTRAN77. 



Table 5-4. Corresponding Identifier Types between ALGOL and FORTRAN?? 



ALGOL 


FORTRAN?? 


REAL ARRAY 


REAL ARRAY/COMMON BLOCK 


INTEGER ARRAY 


INTEGER ARRAY/COMMON BLOCK 


BOOLEAN ARRAY 


LOGICAL ARRAY/COMMON BLOCK 


DOUBLE ARRAY 


COMMON BLOCK 


COMPLEX ARRAY 


COMMON BLOCK 


HEX ARRAY 




ASCII ARRAY 




EBCDIC ARRAY 


CHARACTER COMMON BLOCK 


EBCDIC ARRAY [*] + INTEGER 


CHARACTER ARRAY/CHARACTER 
VARIABLE 

DOUBLE PRECISION ARRAY 
COMPLEX ARRAY 


REAL VARIABLE 


REAL VARIABLE 


INTEGER VARIABLE 


INTEGER VARIABLE 


BOOLEAN VARIABLE 


LOGICAL VARIABLE 


DOUBLE VARIABLE 


DOUBLE PRECISION VARIABLE 


COMPLEX VARIABLE 


COMPLEX VARIABLE 


UNTYPED PROCEDURE 


SUBROUTINE/MAIN PROGRAM 


TYPED PROCEDURE 


FUNCTION 


UNTYPED PROCEDURE + 2 PARAMETERS 
(EBCDIC ARRAY [*] + INTEGER) 


CHARACTER FUNCTION 


FILE 


FILE 


DIRECT FILE 





Global Items 

The only global items that can be shared between ALGOL and FORTRAN?? 
programs are subprograms, files, and common blocks. The common blocks map 
onto ALGOL arrays. 
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Subprograms 

Following are the restrictions to referencing subprograms between ALGOL and 
FORTRAN??: 

• You can replace a FORTRAN?? main program with any ALGOL untyped 
procedure without parameters by binding a separate file containing an 
ALGOL procedure to a FORTRAN?? host program. Use the following Binder 
syntax to indicate the title of the file containing the ALGOL procedure and to 
indicate the name of the ALGOL procedure to use in place of the main 
program, .MAIN.: 

BIND .MAIN. FROM <file specifier> 
USE .MAIN. FOR <identif1er> 

• A FORTRAN?? character function can map only onto an ALGOL untyped 
procedure that has two required leading parameters. The first parameter 
must be a star-bounded EBCDIC array and the second parameter must be an 
integer variable. The EBCDIC array maps onto the value of the character 
function, and the integer variable maps onto the length of the character 
function. 

• Subroutines and functions can be bound or replacement bound into a host 
program that references libraries. 

• New exported subprogram units cannot be added to a host program. 

• Libraries can be added to the host program. 

Files 

An ALGOL file with a declared internal name of FILEnn, where nn is a 1-digit or 
2-digit number from 0 to 99 (without a leading zero), is identified as the same file 
as a FORTRAN?? file with that number. Thus, an ALGOL output statement 
writing to a file declared globally as FILE6 and a WRITE (6,1) statement in a 
FORTRAN?? subprogram bound to that ALGOL host program refer to the same 
file. This method of matching an ALGOL file name with a FORTRAN?? file name 
also applies to the use of ALGOL files as variable files within a FORTRAN?? 
program. For example, if the ALGOL subprogram declares a global file FILE 12 
and writes to it, and the FORTRAN?? host program contains the following 
statements, they both access the same global file, FILE 12: 

IX-12 

READ (IX,7) Y 

iVdIe: The ALGOL print routine performs its carriage control after writing to a 
printer JUe. The FORTRAN print rotitine performs carriage control 
before vrriting to a printer file. To prevent potential printing problems, 
set the WRITEAFTER compiler control option when the ALGOL program 
is compiled. 
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Common Blocks 

In FORTH AN77, there are two types of common blocks: character and arithmetic. 
The character common block maps onto an ALGOL EBCDIC array. The arithmetic 
common block can be accessed by ALGOL as a single-precision array, a 
double-precision array, or as both. 

FORTRAN??, unlike FORTRAN, accesses the common block only through a 
single-precision descriptor and is not affected by odd offsets. 

You must enclose common block names in slashes (/) as in the following example: 

/ABC/ 

To indicate a blank common block, use the following syntax: 
/.BLNK./ 

When a host common block is bound, its resulting length is the longest of all the 
lengths declared for that block in the host program and bound subprograms, 
provided that the FORTRAN?? CODEFILEINIT compiler control option is not set 
in the host program. You cannot extend any common block that has been code file 
initialized. If you attempt an extension. Binder issues the following error 
message: 

COMMON BLOCK CANNOT BE EXTENDED BECAUSE IT IS CODEFILE INITIALIZED 

Accessing FORTRAN?? Common Bloclcs as ALGOL Arrays 

The following paragraphs describe how an ALGOL subprogram can access 
FORTRAN?? arithmetic and character common blocks as ALGOL arrays. 

Single-Precision Array 

To access an arithmetic common block as a single-precision array, declare a global 
ALGOL array and equate it to the FORTRAN?? common block by using the 
Binder USE statement. For example, with a single-precision ALGOL array titled A 
and a FORTRAN?? host common block titled /BLK/, the USE statement is as 
follows: 

USE /BLK/ FOR A; 

Double-Precision Array 

To access an arithmetic common block as a double-precision array, declare the 
ALGOL array as double precision and use the same statement as shown in the 
previous example for a single-precision array. 

Single- and Double-Precision Array 

To access an arithmetic common block as both single- and double-precision 
arrays, declare a single- and a double-precision ALGOL array and equate both 
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arrays to the FORTRAN?? common block with the Binder USE statement. For 
example, with a single-precision array titled A, a double-precision array titled D, 
and a host common block titled /BLK/, the USE statement is as follows: 

USE /BLK/ FOR A,D; 

EBCDIC Array 

To access a character common block as an EBCDIC array, declare a global ALGOL 
EBCDIC array and equate it to the FORTRAN?? common block by using a Binder 
USE statement. 



Using Initial Values with Common Blocks 

You can bind an ALGOL array to a FORTRAN common block that contains 
data-initialized values. Similarly, you can bind a FORTRAN?? common block 
containing initial values to an ALGOL host array if the common block is in a main 
program or a block data subprogram and the FORTRAN?? compiler control option 
CODEFILEINIT is not set during compilation. 

The following are additional restrictions on the use of initial values with common 
blocks in binding: 

• If you plan to data initialize a common block in a given program unit, set 
CODEFILEINIT to avoid losing the data in the common block if the program 
unit is ever replaced. The program unit that replaces the original program 
unit might or might not initialize the common block. 

• If you data initialize a common block in one program unit, and then you bind 
in a different program unit that also initializes the common block, either 
program unit can supply data for the common block. Thus, the results are 
unpredictable. For this reason, you should avoid initializing values for the 
same common block in more than one program unit. 

Accessing ALGOL Arrays from a FORTRAN?? Common Block 

The following paragraphs describe how to access single-precision and EBCDIC 
arrays in an ALGOL host program from the common block of a FORTRAN?? 
subprogram. Double-precision arrays in ALGOL hosts cannot be accessed through 
FORTRAN?? common blocks. 

Sin^e-Precision Array 

To access a single-precision array through an arithmetic common block, declare 
the ALGOL array as a single-precision array and equate the array to the 
FORTRAN?? common block by using the Binder USE statement. For example, 

USE A FOR /BLK/; 

If a common block is equated to an ALGOL array of a different length, the 
resulting array in the bound code file will be the longer of the two lengths, unless 
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the ALGOL array is an equivalence array. If the ALGOL array is an equivalence 
array, the resulting common block will be the size of the array that the 
equivalence array references. 

An equivalence array is an array that is declared to refer to the same data as 
another array. Array B in the following example is an equivalence array. ' 

ARRAY A[0:99]; 
ARRAY B[l] » A; 

EBCDIC Array 

To access an EBCDIC array through a character common block, equate the 
ALGOL array to the FORTRAN?? common block by using the Binder USE 
statement. 



Simulating Common Bloclis in ALGOL 

A FORTRAN?? common block is represented internally as a one-dimensional, 
single-precision array. You can determine the contents of the array by mapping 
the elements of the common declaration onto a contiguous array. You can 
simulate this procedure in ALGOL, as shown in the following example: 

FORTRAN?? Statements 

DOUBLE PRECISION DA (10) 
COMMON /C/ RA(7),X,DA 



ALGOL Statements 

ARRAY C[0:27]; 

DOUBLE ARRAY D[0] = C; 

DEFINE DA(N) = D[(N)+3] #, 

RA(N) = C[{N)-1] #, 

X = C[7] #; 

In this example, subscripts are adjusted so that DA(N) and RA(N) in ALGOL 
reference DA( 10) and RA(?) in the common block. 



Parameters 

When ALGOL and FORTRAN?? program units are bound, only simple variables, 
arrays, and labels can be passed as parameters between program units. 
Procedures, subroutines, functions, and intrinsics cannot be passed as parameters 
between ALGOL and FORTRAN??. 

Binder allows a procedure with unknown parameters to match and bind with a 
procedure of the same name with either known or unknown parameters. 
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When simple variables and arrays are passed as parameters, the following special 
conditions apply: 

• All FORTRAN?? arrays are implemented as one-dimensional arrays. Thus, 
only one-dimensional ALGOL arrays (or array rows) can be passed between 
the two languages. 

• When passing a FORTRAN?? array to an ALGOL array, declare the ALGOL 
array as a star-bounded array. 

• If you use a FORTRAN?? subscript value to evaluate the actual parameter, 
the subscript corresponds to the ALGOL subscript value of 0 (zero). 

• If you do not specify a subscript, the FORTRAN?? array's lower bound is 
used (usually 1). 

• To pass an ALGOL array to a FORTRAN?? subprogram, you must declare the 
array in ALGrOL with a 0 (zero) lower bound (or as star bounded if the array 
is a formal parameter in the ALGOL subprogram). The specified or default 
FORTRAN?? lower bound corresponds to the ALGOL 0 (zero) lower bound. 

• The following conditions apply to arrays: 

- FORTRAN?? double-precision and complex arrays are implemented as 
single-precision arrays that need not be even- word aligned. 

Thus, double-precision and complex arrays do not correspond to any 
ALGrOL array and cannot be passed as parameters between the two 
languages. In some cases, you can override this restriction by using the 
DOUBLEARRAYS compiler control option described in the FORTRAN?? 
Programming Reference Manual. 

- To pass FORTRAN?? character variables and character arrays to ALGOL, 
you must use two consecutive formal arguments in the ALGOL 
subprogram: an ALGOL EBCDIC array with star bounds, and an integer 
variable. 

The characters are passed with a descriptor, an offset, and a character 
length. The descriptor and offset correspond to the EBCDIC array 
argument, and the character length corresponds to the integer variable 
argument. 

• When passing simple variables between FORTRAN?? and ALGOL, you can 
mix by-name and by-value parameters. Note, however, that FORTRAN?? 
by-value parameters are different from ALGOL by-value parameters because 
FORTRAN?? passes noncharacter variables by value-result. 

(Passing by value-result is also known as copy-restore. See "FORTRAN?? 
Intralanguage Binding" in Section 4 for more information about passing 
arguments by value-result.) 

• When mixing by-name and by-value parameters, the following conditions 
apply: 

- If FORTRAN?? calls an ALGrOL procedure and passes a variable as a 
parameter, the variable acts like an ALGOL by-name paraineter in all 
situations. 

- If FORTRAN?? calls an ALGOL procedure and passes an expression as a 
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parameter, the expression acts like an ALGOL by-value parameter in all 

situations. 

- If ALGOL calls a FORTRAN?? program unit and passes a by-name 
parameter to a by-value-result formal parameter, the parameter acts like 
a FORTRAN?? by-value-result parameter. 

- If ALGOL calls a FORTRAN?? program unit and passes a by-value 
parameter, the parameter acts like an ALGOL by-value parameter in all 
situations. 

Example of Binding an ALGOL Subprogram Into a FORTRAN?? 
Host Program 

The following example illustrates a FORTRAN?? host program, an ALGOL 
subprogram, and the Binder input file used to bind them together. The WFL job 
used to compile each program appears in italic type. 

FORTRAN?? Host Program 

7 BEGIN JOB COMPILE/HOST; 

COMPILE F77/H0ST UITH FORTRAN/? LIBRARY; 

FORTRAN?? DATA 
$ SET BINDINFO 

C EMPTY MAIN PROGRAM - IT WILL BE BOUND IN 
END 

SUBROUTINE WORK 

REAL A(3) 

DO 20 I = 1,4 

C THIS LOOP WILL CAUSE AN INVALID INDEX TO OCCUR 
A(I) = 1 

20 CONTINUE 
END 

? END JOB. 
ALGOL Subprogram 

Note that the ALGOL procedure contains an ON INVALIDINDEX statement that 
provides error recovery for the FORTRAN?? program. 

? BEGIN JOB COMPILE/ALGOL; 

COMPILE ALGOL/SUBS ALGOL LIBRARY; 
ALGOL DATA 

[PROCEDURE WORK; EXTERNAL;] 
PROCEDURE MAIN; 
BEGIN 
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LABEL XIT; 

FILE RMT (KIND=REMOTE) ; 
ON INVALIDINDEX: 

BEGIN 

WRITE (RMT,<" INVALID INDEX ">); 
GO TO XIT; 
END; 
WORK; 
XIT: 
END; 
? END JOB. 

Binder Input File 

? BEGIN JOB BIND/INVALID/INDEX; 

BIND PROG BINDER LIBRARY; 

BINDER DATA 

HOST IS F77/H0ST; 

BIND .MAIN. FROM ALGOL/MAIN; 

USE .MAIN. FOR MAIN; 
? END JOB. 

The result of the bind is a file titled PROG. The execution of PROG generates the 
following output: 

INVALID INDEX 

Example of Replacing a FORTRAN?? Character Function by an 
ALGOL Procedure 

The following example shows how a FORTRAN?? character function can be 
replaced by an ALGOL procedure with two leading parameters. The first 
parameter is an EBCDIC array with star bounds. The second parameter is an 
INTEGER variable that contains the length. The WFL job used to compile each 
program appears in italic type. 

FORTRAN?? Host Program 

? BEGIN JOB COMPILE/HOST; 

COMPILE F77/H0ST WITH FORTRAN// LIBRARY; 

FORTRAN?? DATA 
$ SET BINDINFO 

EXTERNAL C 

CHARACTER*6 C. CL 

CL = C(2) 

PRINT *,CL 

END 

? END JOB. 
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ALGOL Subprogram 

? BEGIN JOB COMPILE/ALGOL; 

COMPILE ALGOL/SUBS ALGOL LIBRARY; 
ALGOL DATA 
PROCEDURE C (A,L,I); 
EBCDIC ARRAY A[*]; 
INTEGER L, I; 
BEGIN 

REPLACE A[0] BY "2" FOR I, "4" FOR L-I; 
END; 
? END JOB. 

Binder Input File 

? BEGIN JOB BIND/CHARACTERS; 

BIND PROG BINDER LIBRARY; 

BINDER DATA 

HOST IS F77/HOST; 

BIND - FROM ALGOL/-; 
? END JOB. 

The result of the bind is a file titled PROG. The execution of PROG generates the 
following output: 

224444 

Example of Binding FORTRAN?? Program Units Into an ALGOL 
Host Program 

During a CANDE session, the following two files are created and compiled: 

File Name: ALGOL/HOST 

$ SET WRITEAFTER 
. BEGIN 

FILE FILE6 (KIND=PRINTER) ; 
REAL ARRAY COMM [0:4]; 

% 

% Array COMM is implicitly initialized when MAIN is bound in, 
% even though MAIN is not referenced as a subprogram. 

% 

PROCEDURE MAIN; EXTERNAL; 
PROCEDURE F77SUB; EXTERNAL; 
% 

WRITE (FILE6, */, COMM); 
F77SUB; 
END. 
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FUe Name: F77/SEP 

$ SET SEPARATE 

PROGRAM MAIN 
REAL C(5) 
COMMON /COMM/ C 
DATA C /I, 2, 3. 4, 5/ 

END 

SUBROUTINE F77SUB 
REAL C(5) 
COMMON /COMM/ C 

WRITE (6, *) 'IN SUBROUTINE F77SUB, C - C 

END 

The two code files are bound together by the following Binder program: 



HOST IS OBJECT/ALGOL/HOST; 

BIND MAIN, F77SUB FROM 0BJECT/F77/SEP; 

USE COHM FOR /COMM/; 

The execution of the resulting code file produces the following printed output: 

C0MM[0]-1.0, C0MM(l]-2.0. C0MM[2]-3.0» C0MM[3]-4.0, C0MMt4]=5.0. 
IN SUBROUTINE F77SUB, C = 1.0 2.0 3.0 4.0 5.0 

ALGOL-NEWP Interlanguage Binding 

ALGOL-NEWP interlanguage binding is restricted to binding DCALGOL 
subprograms into a Master Control Program (MCP) host program compiled in 
NEWP. Binder cannot bind DCALGOL subprograms to other host programs 
compiled in NEWP. 

Replacement binding is not allowed for procedures in the NEWP host program, 
except for externals that were bound in and must be rebound. 

Observe the following requirements when binding a DCALGOL subprogram into 
an MCP host program compiled in NEWP: 

• You must compile the subprogram in DCALGOL. 

• You must declare the subprogram as external in the MCP code file. 

• The subprogram cannot add globals to the MCP host program or contain OWN 
variable declarations. 

• The only global variables that the subprogram can reference are those that 
are declared in the outer block of the MCP host program. 

iVote: Becavse of the interaction vrith the NEWP SEPCOMP facility, the old 

object code of procedures being rebound is retained in the MCP code file. 
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The old object code is not referenced and cannot be executed. If many 
rebindings occur, the MCP code file can grow undesirably large with the 
accumulation of useless object code. You can reallocate segments in the 
MCP by recompiling the MCP with the NEWP compiler. 

ALGOL-Pascal Interlanguage Binding 

ALGOL-Pascal interlanguage binding consists of binding an ALGOL subprogram 
into a Pascal host program. Table 5-5 matches identifier types between ALGOL 
and Pascal. 



Table 5>5. Corresponding Identifier Types between ALGOL and Pascal 



ALGOL 


Pascal 


REAL ARRAY [•] 


array of real 

array of record 

array of set 

array of vistring 

array of packed array 

array of explicit type 

long set ( > 48 elements in set) 

record 

vistring 

explicit record (by-vaiue) 
pacl<ed array of real 
packed array of set 
packed array of record 
packed array of vistring 


INTEGER ARRAY [*] 


array of integer 
array of char 
array of enumeration 
array of fixed (n < 12) 
array of sfixed (n < 12) 
array of integer subrange 
array of char subrange 
array of enumeration subrange 
packed array of integer 
packed array of fixed (n < 12) 
packed array of sfixed (n < 12) 
packed array of subrange 

( > 256 elements in subrange) 
packed array of enumeration 

( > 256 elements in enumeration) 


BOOLEAN ARRAY [•] 


array of Boolean 


DOUBLE ARRAY [*] 


array of fixed (n > 1 1) 
array of sfixed (n > 11) 
packed array of fixed (n > 11) 
packed array of sfixed (n > 11) 
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Table 5-5. Corresponding Identifier Types between ALGOL and Pascal (cent.) 



ALGOL 


Pascal 


HEX ARRAY [*] 


hex (n) 




digits (n) 




S—digits (n) 




digits^ (n) 




Boolean 1 




Boolean4 




packed array of Boolean 




packed array of subrange 




(0-16 elenients in subrange) 




packed array of enumeration 




(0-16 elements in enumeration) 


EBCDIC ARRAY [•] 


bits (n) 




binary (n) 




u_display (n) 




z_disolay (n) 




display_z (n) 




s_display (n) 




display_s (n) 




word48 (n) 




word96 (n) 




integer48 




integer96 




real48 




explicit record (var) 




packed array of char 




packed array of subrange 




(17-256 elements in subrange) 




packed array of enumeration 




(17-256 elements in enumeration) 


REAL VARIABLE 


real 








(1-48 elements in set) 


INTEGER VARIABLE 






char 




enumeration 




fixed (n < 12) 




sfixed (n < 12) 




integer subrange 




char subrange 




enumeration subrange 


BOOLEAN VARIABLE 


Boolean 




Boolean subrange 


DOUBLE VARIABLE 


fixed (n > 11) 




sfixed (n > 11) 


PROCEDURE 


procedure 


REAL PROCEDURE 


function : real 
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Table 5-5. Corresponding Identifier Types between ALGOL and Pascal (cent.) 



ALGOL 


Pascal 


INTEGER 
PROCEDURE 


function : integer 
function : char 
function : enumeration 
function : fixed (n < 12) 
function : sfixed (n < 12) 
function : integer subrange 
function : char subrange 
function : enumeration subrange 


BOOLEAN 
PROCEDURE 


function : Boolean 
function : Boolean subrange 


DOUBLE 
PROCEDURE 


function : fixed (n > 11) 
function : sfixed (n > 11) 



Global Items 

Pascal and ALGOL programs can share global items. When binding global items 
from an ALGOL subprogram into a Pascal host program, you must write a Pascal 
module heading that describes the ALGOL subprogram in Pascal terms. You 
include ALGOL global variables in the export declaration of the Pascal module 
heading as shown in the following portion of Pascal syntax: 

MODULE ni EXTERNAL; 

EXPORT int( a, p, f ); 
VAR a : integer; 
PROCEDURE p ( param : integer); 
FUNCTION f : integer; 
END; 

The EXTERNAL directive indicates that the module is written in a language other 
than Pascal. When a Pascal host program is compiled with modules that are 
declared with the EXTERNAL directive or modules that use other modules that 
are declared as external, the Pascal compiler creates a BINDERINPUT file. This 
file contains a set of suggested comimands for Binder to use when binding the 
procedures compiled in the other language. 

For example, when binding an ALGOL subprogram into a Pascal host program, 
the Pascal compiler puts USE statements in the BINDERINPUT to equate variable 
identifiers in Pascal and ALGOL. The USE statements are necessary because the 
Pascal compiler names the Pascal identifier by assigning the module name 
followed by a slash (/) and the ALGOL identifier name. 

For example, assuming that the external module is titled m and an ALGOL 
variable is declared as a, as in the preceding example, the BINDERINPUT file 
would contain the following Binder USE statement: 



5-24 



8600 0304-000 



Binding Programs Written in Different Languages 



USE M/A FOR A 

There might be times when you need to edit the BINDERINPUT file. The internal 
name of the file for file equation is BINDERINPUT. 

For more information about the BINDERINPUT file, the EXTERNAL directive, 
and modules, refer to the A Series Pascal Programming Reference Mantial, 
Volume 1. 



Parameters 

The following restrictions apply to parameters passed between ALGOL and 

Pascal: 

• You cannot pass text files between ALGOL and Pascal. 

• You can pass standard files between ALGOL and Pascal; however, you must 
declare in the Pascal host program the files that can be passed. Refer to the 
example following this discussion to see the code for a Pascal host program 
that passes standard files. For more information on Pascal file syntax, refer 
to the Pascal Reference Manual, Vohmie 1 . 

• Procedures and functions are allowed as parameters to ALGOL procedures 
bound to Pascal programs. 

• Parameters passed between a Pascal host program and an ALGOL subprogram 
must match. 

• Variables passed by reference (that is, variable parameters) in a Pascal host 
program must match by-name parameters in the ALGOL subprogram. 

• Variables passed by value in a Pascal host program must match by-value 
parameters in the ALGOL subprogram. 

• Binder allows a procedure with unknown parameters to match and bind with 
a procedure of the same name with either known or unknown parameters. 

Examples of Binding An ALGOL Subprogram Into a Pascal Host 
Program 

Example 1 

The following example shows how a Pascal program can incorporate a module 
written in ALGOL. The module heading describes an ALGOL procedure with one 
global variable, one untyped procedure, and one typed procedure to be bound into 
a Pascal program or library. The WFL job used to compile each program appears 
in italic type. 

Pascal Host Program 

? BEGIN JOB COMPILE/HOST; 
COMPILE PASCAL/HOST UITH PASCAL LIBRARY; 
PASCAL DATA CARD 
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MODULE m EXTERNAL; 
c EXPORT int ( a, p, f ); 

VAR a : integer; 

PROCEDURE p ( param : integer); 

FUNCTION f : integer; 
END; 

PROGRAM prog; 

IMPORT int; 

VAR ig : integer; 
BEGIN 
P (42); 
ig := f; 

DISPLAY (concat ('value of a is string(a))); 
DISPLAY (concat ('value of ig is ', string(ig))); 
END. 
? END JOB. 

The BINDERINPUT file created by the Pascal compiler is as follows. You can use 
this file to bind the Pascal host program, PASCAL/HOST, and the ALGOL 
subprogram, OBJECT/M. 

$ RESET LIST 
USE M/A FOR A; 
USE M/F FOR F; 
USE M/P FOR P; 
BIND 

M/F, 

M/P, 

DUMMY FROM OBJECT/M; 
HOST IS PASCAL/HOST; 

ALGOL Subprogram 

? BEGIN JOB MODULE/BODY; 
COMPILE OBJECT/M UITH ALGOL LIBRARY; 
ALGOL DATA CARD 
$ SET LEVEL 3 LIBRARY 
[ INTEGER A; ] 
PROCEDURE P ( I ); 

VALUE I; INTEGER I; 
BEGIN 

DISPLAY ("CALL ON P EXECUTED WITH I = " CAT STRING(I,*)) ; 

A := 399; 

END; 

INTEGER PROCEDURE F; 
BEGIN 

DISPLAY ("CALL ON F EXECUTED"); 
F := 7; 
END; 
? END JOB. 
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When executed, the newly bound program displays the following: 

CALL ON P EXECUTED WITH I » 42 
CALL ON F EXECUTED 
value of a Is 399 
value of 1g 1s 7 

Example 2 

The following example shows a Pascal host program that has an ALGOL 
procedure bound into it. In this example, the formal parameter f represents an 
ALGOL file. In the Pascal host program, this formal parameter is compatible with 
any standard file parameter. 

For this example, FILE OF char is the standard file parameter. Note that the 
Pascal buffer variable f@, is not affected by any input or output that occurs 
during the execution of the bound-in procedure. 

MODULE m EXTERNAL; 
EXPORT i(p); 

PROCEDURE p (VAR f: stdfile ) 
END; 

PROGRAM p; 
IMPORT i; 

TYPE tf- FILE OF char; 

VAR myf : tf ; 
BEGIN 

p( myf ) 
END. 

COBOL-FORTRAN Interlanguage Binding 

COBOL-FORTRAN interlanguage binding consists of binding a COBOL program 
into a FORTRAN host program or binding a FORTRAN subprogram into a COBOL 
host program. Table 5-6 matches identifier types between COBOL and FORTRAN. 



Table 5-6. Corresponding Identifier Types between COBOL and FORTRAN 



COBOL 


C0B0L74 


FORTRAN 


COMP OCCURS 
COMP OCCURS 
COMP OCCURS 


REAL OCCURS 

BINARY OCCURS 

BINARY OCCURS 

DOUBLE PRECISION 
ARRAY/COMMON BLOCK 


REAL ARRAY/COMMON 
BLOCK 

INTEGER 

ARRAY/COMMON BLOCK 
LOGICAL 

ARRAY/COMMON BLOCK 
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Table 5-6. Corresponding Identifier Types between COBOL and 

FORTRAN (cent.) 



COBOL 


COBOL74 


FORTRAN 




COMPLEX 

ARRAY/COMMON dLUCK 




COMP-Z 






ASCII 






DISPLAY 


DISPLAY 




DISPLAY LOWERBOUNDS 
+ LEVEL 77 


DISPLAY LOWERBOUNDS 
+ LEVEL 77 




COMP-4 


REAL 


REAL VARIABLE 


COMP or COMP-1 


BINARY (1 to 11 digits) 


INTEGER VARIABLE 


COMP or COMP-1 


BINARY (1 to 11 digits) 


LOGICAL VARIABLE 


COMP-5 


DOUBLE 

COMPLEX VARIABLE 


DOUBLE PRECISION 
VARIABLE 


SECTION 


SECTION 
FUNCTION 


SUBROUTINE 


SECTION + 2 
PARAMETERS (DISPLAY 
LOWERBOUNDS + LEVEL 
77) 


SECTION + 2 
PARAMETERS (DISPLAY 
LOWERBOUNDS + LEVEL 
77) 




FILE 


FILE 


FILE 


DIRECT FILE 


DIRECT FILE 





Global Items 

Only files and FORTRAN subprograms can be shared globally between COBOL 
and FORTRAN. Files in FORTRAN are given the internal name, FILEnn, where nn 
is a 1-digit or 2-digit number (without a leading zero) that refers to the unit 
number in a FORTRAN I/O statement. 

For example, a WRITE(6,1) statement in a FORTRAN subroutine writes to FILE6. 
To share a common file with FORTRAN, a COBOL file must be named and 
declared accordingly. 
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Parameters 

The following restrictions apply when passing parameters between COBOL and 
FORTRAN: 

• You can pass only arrays and simple variables (declared as 77-level items in 
COBOL) as parameters between FORTRAN and COBOL. 

• You must declare COBOL array parameters as REAL or BINARY in COBOL74 
and COBOL85, or COMPUTATIONAL in COBOL68, because FORTRAN works 
only with word-oriented arrays. 

• When passing an array from FORTRAN to COBOL, include a LOWER-BOUNDS 

clause in the 01-level description for the array. When passing an array from 
COBOL to FORTRAN, you must also include a LOWER-BOUNDS clause in the 
LOCAL-STORAGE SECTION description of the formal parameters. 

• COBOL always assumes that the lower bound of an array that is passed or 
received is 0 (zero). 

• Unpredictable results can occur if you pass to COBOL a FORTRAN 
subscripted variable with a value other than 0 (zero). 

• You should pass only the first array appearing in a FORTRAN common block 
to COBOL. Otherwise, results are unpredictable. 

• You cannot pass subroutines and functions as parameters between COBOL 
and FORTRAN. 

• Binder allows a procedure with unknown parameters to match and bind with 
a procedure of the same name with either known or unknown parameters. 

C0B0L-F0RTRAN77 Interlanguage Binding 

COBOL-FORTRAN?? interlanguage binding consists of binding either a COBOL 
program into a FORTRAN?? host program or a FORTRAN?? subprogram into a 
COBOL host program. Table 5-? matches identifier types between COBOL and 
FORTRAN??. 



Table 5-7. Corresponding Identifier Types between COBOL and FORTRAN?? 



COBOL 


COBOL74 


FORTRAN?? 


COMP OCCURS 
COMP OCCURS 
COMP OCCURS 
COMP-2 


REAL OCCURS 
BINARY OCCURS 
BINARY OCCURS 


REAL ARRAY/COMMON 

BLOCK 

INTEGER 

ARRAY/COMMON BLOCK 
LOGICAL 

ARRAY/COMMON BLOCK 
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Table 5-7. Corresponding Identifier Types between COBOL and 
FORTRAN?? (cent.) 



COBOL 


C0B0L74 


FORTRAN?? 


ASCII 






DISPLAY 


DISPLAY 


CHARACTER COMMON 
BLOCK 


DIorLAY LUWcKBOUNDo 
+ LEVEL 77 


IJISrLAY LOWcRdUUNDS 
+ LEVEL 77 


CHARACTER 
ARRAY/CHARACTER 

VARIABLE 

>^ 

DOUBLE PRECISION 
ARRAY 

COMPLEX ARRAY 


COMP-4 


REAL 


REAL VARIABLE 


COMP or COMP-1 


BINARY (1 to 11 digits) 


INTEGER VARIABLE 


COI^P or COMP-1 


BINARY (1 to 11 digits) 


LOGICAL VARIABLE 


COIVIP-5 


DOUBLE 


DOUBLE PRECISION 
VARIABLE 

COMPLEX VARIABLE 


ocLr 1 lUIN 


otXt 1 lUN 


CI IDDOI IXIKICT /RilAIKi 

PROGRAM 
FUNCTION 


SECTION + 2 
PARAMETERS (DISPUY 
LOWERBOUNDS + LEVEL 
77) 


SECTION + 2 
PARAMETERS (DISPLAY 
LOWERBOUNDS + LEVEL 
77) 


CHARACTER FUNCTION 


FILE 


FILE 


FILE 


DIRECT FILE 


DIRECT FILE 





Global Items 

Only files and FORTRAN?? subprograms can be shared globally between COBOL 
and FORTRAN??. Files in FORTRAN?? are given the internal name, FILEnn, 
where nn is a 1 -digit or 2-digit number (without a leading zero) that refers to the 
unit number in a FORTRAN?? I/O statement. For example, a WRITE(6,1) 
statement in a FORTRAN?? subroutine writes to FILE6. To share a common file 
with FORTRAN??, a COBOL file must be named and declared accordingly. 

You can simulate a character function in COBOL with a COBOL section that has 
two leading parametiers. These parameters must be a DISPLAY array with the 
LOWER-BOUNDS clause and a ??-level item declared BINARY in C0B0L?4 and 
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COBOL85, or COMP-1 in COBOL68. The second parameter corresponds to the 
character length of the character function. 



Parameters 

The following restrictions apply to parameters passed between FORTRAN?? and 
COBOL: 

• You can pass only simple characters, arrays, and variables (declared as 
77-level items in COBOL) as parameters between FORTRAN?? and COBOL. 

• When passing an array from FORTRAN?? to COBOL, include a 
LOWER-BOUNDS clause in the 01-level description for the array. When 

passing an array from COBOL to FORTRAN??, you must also include a 
LOWER-BOUNDS clause in the LOCAL-STORAGE SECTION description of the 
formal parameters. 

• COBOL always assumes that the lower bound of an array that is passed or 

received is 0 (zero). 

• Unpredictable results can occur if you pass to COBOL a FORTRAN?? 
subscripted variable with a value other than 0 (zero). 

• You should pass only the first array appearing in a FORTRAN?? common 
block to COBOL. Otherwise, the results are unpredictable. 

• All FORTRAN?? character variables are stored in a character pool. You 
should pass to COBOL only the first FORTRAN?? character variable in the 
pool. Otherwise, the results are unpredictable. 

• You cannot pass subroutines and functions as parameters between COBOL 
and FORTRAN??. 

• Binder allows a procedure with unknown parameters to match and bind with 
a procedure of the same name with either known or unknown parameters. 

Example of Passing a FORTRAN?? Character Variable to a 
C0B0L?4 Section 

The following example shows a FORTRAN?? host program, a COBOL subprogram, 
and the Binder input file used to bind them together. The WFL job used to 
compile each program appears in italic type. 

FORTRAN?? Host Program 

? BEGIN JOB COMPILE/HOST; 

COMPILE F77/H0ST UITH FORTRAN?? LIBRARY-, 

FORTRAN?? DATA 
$ SET BINDINFO 

CHARACTER*? C 

CALL SUB (C) 

PRINT *,C 
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END 

7 END JOB. 

COBOL Subprogram 

? BEGIN JOB C0MPILE/C0B0L74; 

COMPILE C0B0L74/SUB C0B0L74 LIBRARY; 
C0B0L74 DATA 
$ SET LEVEL =3 

IDENTIFICATION DIVISION. 

PROGRAM- ID. EXAMPLE. 

ENVIRONMENT DIVISION. 

CONFIGURATION SECTION. 

SOURCE-COMPUTER. A- 15. 

OBJECT-COMPUTER. A- 15. 

DATA DIVISION. 

WORKING-STORAGE SECTION. 

01 COBARY DISPLAY LOWER-BOUNDS RECEIVED BY REFERENCE. 

03 DUMMY PIC X(l) OCCURS 7 TIMES. 
01 FAKEIT REDEFINES COBARY. 

03 NUMB PIC X(7). 
77 LEN BINARY PIC 9(11). 
PROCEDURE DIVISION USING COBARY, LEN. 
CB SECTION. 
STORE- VALUE. 

MOVE ' 'ABCDEFG' ' TO NUMB. 

? END JOB. 
Binder Input File 

? BEGIN JOB BIND/C0B0L74; 

BIND PROG BINDER LIBRARY; 

BINDER DATA 

HOST IS F77/HOST; 

BIND SUB FROM C0B0L74/SUB; 

USE SUB FOR CB; 
? END JOB. 

The result of the bind is an object file titled PROG. When executed, PROG 
generates the following output: 

ABCDEFG 
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COBOL-Pascal Interlanguage Binding 

COBOL-Pascal interlanguage binding consists of binding a COBOL subprogram 
into a Pascal host program. 



Table 5-8. Corresponding Identifier Types between COBOL and Pascal 



COBOL 


C0B0L74 


Pascal 


COMP OCCURS 


REAL OCCURS 


array of real 






array of record 






array of set 






array of vistring 






array of packed array 






array of explicit type 






long set ( > 48 elements in set) 






record 






vistring 






explicit record (by-value) 






packed array of real 






packed array of set 






packed array of record 






packed array of vistring 


COMP OCCURS 


BINARY 


array of integer 




OCCURS 


array of char 






array of enumeration 






array of fixed (n < 12) 






array of sfixed (n < 12) 






array of integer subrange 






array of char subrange 






array of enumeration subrange 






packed array of integer 






packed array of fixed (n < 12) 






packed array of sfixed (n < 12) 






packed array of subrange 






( > 256 elements in subrange) 






packed array of enumeration 






( > 256 elements in enumeration) 


COMP OCCURS 


BINARY 


array of Boolean 




OCCURS 


array of fixed (n > 1 1) 






array of sfixed (n > 11) 






packed array of fixed (n > 1 1) 






packed array of sfixed (n > 11) 
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Table 5-8. Corresponding Identifier Types between COBOL and Pascal (cent.) 



COBOL 


COBOL74 


Pascal 






array of fixed (n > 1 1) 






array of sfixed (n > 11) 






packed array of fixed (n > 11) 






packed array of sfixed (n > 11) 


COMP-2 




hex(n) 






digits (n) 






s_digits (n) 






digits— s (n) 






Boolean 1 






Boolean4 






packed array of Boolean 






packed array of subrange 






(0-16 elements in subrange) 






packed array of enumeration 






(0-16 elements in enumeration) 


DISPLAY 


DISPLAY 


bits (n) 






binary (n) 






u_display (n) 






z-jdisplay (n) 






display_z (n) 






s_display (n) 






display_s (n) 






word48 (n) 






word96 (n) 






Integer48 






integer96 






real48 






explicit record (var) 






packed array of char 






packed array of subrange 






(17-256 elements in subrange) 






packed array of enumeration 






(17-256 elements in enumeration) 


COMP-4 


REAL 


real 






short set 






(1-48 elements in set) 
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Table 5-8. Corresponding identifier Types between COBOL and Pascal (cont.) 



COBOL 


C0B0L74 


Pascal 


COMP OR 
COMP-1 


BINARY (1 to 
11 digits) 


integer 
char 

enumeration 
fixed (n < 12) 
sflxed (n < 12) 
integer subrange 
char subrange 
enumeration subrange 


COMP OR 
COMP-1 


BINARY (1 to 
11 digits) 


Boolean 

Boolean subrange 


COMP-5 


DOUBLE 


fixed (n > 11) 
sflxed (n> 11) 


SECTION 


SECTION 


procedure 

function : real 

function : integer 
function : char 
function : enumeration 
function : fixed (n < 12) 
function : sflxed (n < 12) 
function : integer subrange 
function : char subrange 
function : enumeration subrange 

function : Boolean 
function : Boolean subrange 

function : fixed (n > 11) 
function : sflxed (n > 11) 



Global Items 

You can share global items between Pascal and COBOL. If a COBOL subprogram 
is to reference a global variable in a Pascal host program, you must declare the 
variable by using the GLOBAL clause or the GLOBAL compiler control option in 
the COBOL subprogram. 
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When binding global items from a COBOL subprogram into a Pascal host program, 
you must write a Pascal module heading that describes the COBOL subprogram in 
Pascal terms. You include COBOL global variables in the export declaration of the 
Pascal module heading as shown in the following portion of Pascal syntax: 

MODULE m EXTERNAL; 
EXPORT int( a, p); 
VAR a : integer; 

PROCEDURE p (var param : integer); 
END; 

The EXTERNAL directive indicates that the module is written in a language other 
than Pascal. When a Pascal host program is compiled with modules that are 
declared with the EXTERNAL directive or modules that use other modules that 
are declared as EXTERNAL, the Pascal compiler creates a BINDERINPUT file. 
This file contains a set of suggested commands for Binder to use when binding 
the procedures compiled in the other language. 

For example, when binding a COBOL subprogram into a Pascal host program, the 
Pascal compiler puts USE statements in the BINDERINPUT to equate variable 
identifiers in Pascal and COBOL. The USE statements are necessary because the 
Pascal compiler names the Pascal identifier by assigning the module name 
followed by a slash (/) and the COBOL identifier name. 

For example, assuming that the external module is named m and the COBOL 
variables are declared as a and p, as in the preceding example, the 
BINDERINPUT file would contain the following Binder USE statement: 

USE M/A FOR A; 
USE M/P FOR P; 

There might be times when you need to edit the BINDERINPUT file. The internal 
name of the file for file equation is BINDERINPUT. 

For more information about the BINDERINPUT file, the EXTERNAL directive, 
and modules, refer to the Pascal Reference Marmal, Volume 1. 

Parameters 

The following restrictions apply when passing parameters between Pascal and 

COBOL: 

• When passing a word-oriented variable or array (integer, real, or Boolean) 
between Pascal and COBOL68, declare the word-oriented entity as 
COMPUTATIONAL in the COBOL68 program. You can declare real variables 
as COMPUTATIONAL-4. 

• In a COBOL74 program, you must declare a real array or variable as REAL, 
and an integer or Boolean array or variable as BINARY. 

• You cannot pass text files between Pascal and COBOL. 
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• You can pass standard files between COBOL and Pascal; however, you must 
declare in the Pascal host program the files that can be passed. Refer to the 
example following this discussion to see the code for a Pascal host program 
that passes standard files. For more information on Pascal file syntax, refer 
to the Pascal Reference Manual, Volume 1. 

• Binder allows a procedure with unknown parameters to match and bind with 
a procedure of the same name with either known or unknown parameters. 

Example of Binding a COBOL74 Procedure into a Pascal Host 
Program 

The following example shows how a Pascal program can incorporate a module 
written in another language. The module heading describes a COBOL74 procedure 
with one global variable to be bound into a Pascal program or module. The WFL 
job used to compile each program appears in italic type. 

Pascal Host Program 

? BEGIN JOB COMPILE/HOST; 

COMPILE PASCAL/HOST UITH PASCAL LIBRARY; 
PASCAL DATA CARD 
MODULE m EXTERNAL; 

EXPORT int( a, p); 

VAR a : integer; 

PROCEDURE p(var param : integer); 
END; 

PROGRAM prog; 

IMPORT int; 

VAR i : integer; 
BEGIN 
P(i); 

DISPLAY (concat ('value of 1 is ' ,string(i))); 
DISPLAY (concat ('value of a is ' .string (a))); 
END. 
? END JOB. 

The Pascal compiler produces the following BINDERINPUT file. You can use this 
file to bind the Pascal host program, PASCAL/HOST, and the COBOL subprogram, 
OBJECT/M. 

$ RESET LIST 
USE M/A FOR A; 
USE M/P FOR P; 
BIND 
M/P, 

DUMMY FROM OBJECT/M; 
HOST IS PASCAL/HOST; 
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COBOL74 Subprogram 

1 BEGIN JOB MODULE/BODY; 

COMPILE OBJECT/M UITH C0B0L74 LIBRARY; 
C0B0L74 DATA CARD 
$ SET LEVEL = 3 

IDENTIFICATION DIVISION. 

ENVIRONMENT DIVISION. 

DATA DIVISION. 

WORKING-STORAGE SECTION. 

77 A PIC S9(ll) GLOBAL BINARY. 

77 I PIC S9(ll) LOCAL BINARY RECEIVED BY REFERENCE. 

PROCEDURE DIVISION USING I. 

LBL. 

DISPLAY "CALL ON SUBPROGRAM EXECUTED". 
MOVE 111 TO I. 
MOVE 399 TO A. 
EXIT PROCEDURE. 

? END JOB. 

When executed, the bound program generates the following output: 

CALL ON SUBPROGRAM EXECUTED 
value of 1 is 111 
value of a is 399 

Example of Binding a COBOL Procedure Into a Pascal Host 
Program 

The following example shows a Pascal host program that has a procedure bound 
into it. In this example, the formal parameter (f) represents a COBOL file. In the 
Pascal host program, this formal parameter is compatible with any standard file 
parameter. For this example, FILE OF char is the standard file parameter. Note 
that the Pascal buffer variable y@ is not affected by any input or output that 
occurs during the execution of the bound-in procedure. 

MODULE m EXTERNAL; 
EXPORT i(p); 

PROCEDURE p (VAR f: stdfile ) 
END; 

PROGRAM p; 
IMPORT i; 

TYPE tf= FILE OF char; 

VAR myf : tf ; 
BEGIN 

P( myf ) 
END. 
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FORTRAN-FORTRAN?? Interlanguage Binding 

FORTRAN-FORTRAN?? interlanguage binding consists of binding a FORTRAN 
subprogram into a FORTRAN?? host program or binding a FORTRAN?? 
subprogram into a FORTRAN host program. You cannot bind a FORTRAN?? 
subroutine with a label parameter into a FORTRAN host program. 

Table 5-9 matches identifier types between FORTRAN and FORTRAN??. 



Table 5-9. Corresponding Identifier Types between FORTRAN and 

FORTRAN?? 



FORTRAN 


FORTRAN?? 


REAL ARRAY/COMiy^ON BLOCK 


REAL ARRAY/COMMON BLOCK 


INTEGER ARRAY/COMMON BLOCK 


INTEGER ARRAY/COMMON BLOCK 


LOGiCAL ARRAY/COMMON BLOCK 


LOGICAL ARRAY/COMMON BLOCK 


DOUBLE PRECISION ARRAY/COMMON 


COMMON BLOCK 


BLOCK 




COMPLEX ARRAY/COMMON BLOCK 


COMMON BLOCK 




CHARACTER COMMON BLOCK 




CHARACTER ARRAY/CHARACTER 




VARIABLE 




DOUBLE PRECISION ARRAY 




COMPLEX ARRAY 


REAL VARIABLE 


REAL VARIABLE 


INTEGER VARIABLE 


INTEGER VARIABLE 


LOGICAL VARIABLE 


LOGICAL VARIABLE 


DOUBLE PRECISION VARIABLE 


DOUBLE PRECISION VARIABLE 


COMPLEX VARIABLE 


COMPLEX VARIABLE 


SUBROUTINE 


SUBROUTINE/MAIN PROGRAM 


FUNCTION 


FUNCTION 




CHARACTER FUNCTION 


FILE 


FILE 



Subprograms 

A FORTRAN subprogram can be a FORTRAN subroutine or function. A 
FORTRAN?? subprogram can be a FORTRAN?? main program, subroutine, 
function, or block data subprogram. 
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A FORTRAN?? main program is compatible with a FORTRAN subroutine that has 
no parameters. Thus, you can bind a FORTRAN?? main program into a 
FORTRAN?? host program by replacing the main program with a separately 
compiled FORTRAN subroutine. 

Use the following Binder syntax to indicate the title of the file containing the 
FORTRAN subroutine and to indicate the name of the FORTRAN subroutine to 
use in place of the FORTRAN?? main program, .MAIN. : 

BIND .MAIN. FROM <file specif ier> 
USE .MAIN. FOR <identifier> 

Unlike FORTRAN?? main programs, FORTRAN main programs cannot be bound 
or replacement bound by a host program. 

Exported subroutines and functions can be replacement bound. It is not possible 
to add new exported program units to a host program. 

Common Blocks 

FORTRAN?? arithmetic common blocks correspond to FORTRAN common blocks. 
However, FORTRAN?? accesses the common block only through a single-precision 
descriptor and is not affected by odd offsets. 

When a common block is bound, its resulting length is the longest of all the 
lengths declared for that block in the host program and bound subprograms, 
unless the FORTRAN?? compiler control option CODEFILEINIT is set in the host 
program. 

Any common block that has been code file initialized cannot be extended. 

Parameters 

FORTRAN?? double-precision and complex arrays are passed to subprograms as 
single-precision descriptors. The array elements do not have to be on even-word 
boundaries. For this reason, the FORTRAN?? arrays do not correspond to any 
FORTRAN array and, thus, cannot be passed as parameters between the two 
languages. (In some cases, you can override this restriction by using the 
DOUBLEARRAYS compiler control option described in the FORTRAN?? Reference 
Mantml.) 

You cannot pass subroutines and functions as parameters between FORTRAN?? 
and FORTRAN. 

Binder allows a procedure with unknown parameters to match and bind with a 
procedure of the same name with either known or unknown parameters. 
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Characters 

FORTRAN?? character variables, character arrays, and character common blocks 
do not correspond to any FORTRAN data structure. 

Libraries 

You can bind or replacement bind subroutines and functions into a host program 
that references libraries. You can also add libraries to the host program. 

When compiling subprograms, declare all libraries used by the subprograms 
before the first executable program unit. 

Libraries in subprograms to be bound to a host program do not have to be 
explicitly declared in the host program. If libraries are not declared in the host 
program, Binder builds a library template from the binding information in the 
subprogram file. Once the template is built, Binder can add library objects not 
explicitly declared in the host. 

Subprograms that do not reference libraries can be bound into host programs that 
reference libraries or that are themselves libraries. 

FORTRAN describes all simple variable arguments to imported subprograms as 
call-by-reference. FORTRAN?? describes them as call-by-name. When calling a 
library object. Binder allows call-by-reference and call-by-name arguments to 
match at run time. 

Example of Binding a FORTRAN Common Block Into a 
FORTRAN?? Host Program 

The following example shows a FORTRAN?? host program, a FORTRAN 
subprogram, and the Binder input file used to bind them together. The WFL job 
used to compile each program appears in italic type. 

FORTRAN?? Host Program 

? BEGIN JOB COMPILE/HOST; 

COMPILE F77/H0ST UITH FORTRAN?/ LIBRARY; 

FORTRAN?? DATA 
$ SET BINDINFO 

COMMON A,B,C,D 

DATA A,B.C,D 71,1,1,1/ 

CALL SUB 

WRITE (6,*) A,B,C,D 
END 

? END JOB. 
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FORTRAN Subprogram 

7 BEGIN JOB COMPILE/FORTRAN; 

COMPILE FORTRAN/SUB FORTRAN LIBRARY; 

FORTRAN DATA 
$ SET SEPARATE 

SUBROUTINE SUB 

COMMON ONE, TWO 

DOUBLE PRECISION ONE, TWO 

TWO « 2 

END 

? END JOB. 
Binder Input File 

? BEGIN JOB BIND/CHARACTERS; 

BIND PROG BINDER LIBRARY; 

BINDER DATA 

HOST IS F77/H0ST; 

BIND = FROM FORTRAN/-; 
? END JOB. 

The result of the bind is an object file titled PROG. When executed, PROG 
generates the following output: 

2*1.0 2.0 0.0 



Example of Interlanguage Binding Involving FORTRAN??, 
C0B0L?4, and ALGOL 

The following is a complex example of interlanguage binding. The host program is 
a FORTRAN?? program that passes an array as a parameter to a COBOL74 
program. The COBOL74 program calls an ALGOL procedure, that in turn calls 
another COBOL74 program. The WFL job used to compile each program appears 
in italic type. 

FORTRAN?? Host Program 

The WFL job compiles and saves the program. 

? BEGIN JOB COMPILE/HOST; 

COMPILE F0RTRAN77/H0ST FORTRAN LIBRARY; 
FORTRAN?? DATA 
DIMENSION A(7) 

C PLACE ALPHABET IN A(l)-A(5) 

CALL MOVE (A(l) , ' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ ' ' ,30) 

C NOW CALL THE COBOL PROGRAM 
CALL COBPRO(A) 
STOP 
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END 

? END JOB, 
COBOL74 Subprogram 

The following WFL job compiles the COBOL74 program called from the 
FORTRAN77 host program and saves it in the file named SEP/COBPRO. 

? BEGIN JOB C0MPILE/5EP/C0BPR0; 

COMPILE SEP/COBPRO C0B0L74 LIBRARY; 
C0B0L74 DATA 
$ SET LEVEL - 3 

IDENTIFICATION DIVISION. 

PROGRAM- ID. NUMBERS. 

ENVIRONMENT DIVISION. 

CONFIGURATION SECTION. 

SOURCE-COMPUTER. A- 15. 

OBJECT-COMPUTER. A- 15. 

DATA DIVISION. 

WORKING-STORAGE SECTION. 

01 COBARY COMP LOWER-BOUNDS REFERENCE. 

03 DUMMY PIC 9(11) OCCURS 7 TIMES. 

01 FAKEOUT REDEFINES COBARY. 

03 FILLER PIC X(30). 

03 NUMB PIC X(12). 

LOCAL- STORAGE SECTION. 
LD PASS. 
01 LARY COMP. 

03 OTHER-DUMMY PIC 9(11) OCCURS 7 TIMES. 
PROCEDURE DIVISION USING COBARY. 
DECLARATIVES. 
Al SECTION. 

USE EXTERNAL PROCEDURE WITH PASS USING LARY. 
END DECLARATIVES. 
SI SECTION. 
PUT-IN-NUMBERS. 

MOVE "0123456789 " TO NUMB. 

ENTER Al USING COBARY. 

? END JOB. 
ALGOL Subprogram 

The following WFL job compiles the ALGOL procedure called from the COBOL 
program and saves it in the file named SEP/AL6. 

? BEGIN JOB COMPILE/SEP/ALG; 

COMPILE SEP/ALG ALGOL LIBRARY; 
ALGOL DATA 

[PROCEDURE COBPRINT(A,B); ARRAY A,B[0]; EXTERNAL;] 
$ SET LEVEL 4 

PROCEDURE ALG (ARGOLO) ; 
ARRAY ARGOLD[0]; 
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BEGIN 

INTEGER M; 
ARRAY ARGNU [0:6]; 
POINTER PN,PO,POT; 
PO :« POT :« P0INTER(ARG0L0[6])-t-5; 
PN :» POINTER(ARGNU) ; 
FOR M :« 0 STEP 1 UNTIL 41 DO 
BEGIN 
PO POT-M; 

REPLACE PN-^M BY PO FOR 1; 
END; 

COBPRINT(ARGOLD,ARGNU) ; 
END; 
? END JOB. 

COBOL74 Subprogram 

The following WFL job compiles the COBOL74 program called from the AIXiOL 
procedure and saves it in the file named SEP/COBPRINT. 

? BEGIN JOB COMPILE/SEP/COBPRINT; 

COMPILE SEP/COBPRINT C0B0L74 LIBRARY; 
C0B0L74 DATA 
$ SET LEVEL - 3 

IDENTIFICATION DIVISION. 

PROGRAM-ID. PRINT/ARRAYS. 

ENVIRONMENT DIVISION. 

CONFIGURATION SECTION. 

SOURCE-COMPUTER. A- 15. 

OBJECT-COMPUTER. A- 15. 

INPUT-OUTPUT SECTION. 

FILE-CONTROL. 

SELECT PR ASSIGN TO PRINTER. 

DATA DIVISION. 

FILE SECTION. 

FD PR. 

01 PR-RCD PIC X(42). 

WORKING-STORAGE SECTION. 
01 A COMP REFERENCE. 

03 DUMMY PIC 9(11) OCCURS 7 TIMES. 

01 B COMP REFERENCE. 

03 OTHER-DUMMY PIC 9(11) OCCURS 7 TIMES. 
PROCEDURE DIVISION USING A B. 
CB SECTION. 
OPEN -PR. 

OPEN OUTPUT PR. 

WRITE PR-RCD FROM A. 

WRITE PR-RCD FROM B. 

? END JOB. 
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Binder Input File 

The four files are then bound and executed by the following WFL job: 

? BEGIN JOB BIND/EXAMPLE/PROG; 
BIND EXAMPLE/PROG BINDER; 
BINDER DATA 

HOST IS FORTRAN77/HOST; 
USE Al FOR ALG; 
BIND Al FROM SEP/ALG; 
BIND = FROM SEP/=; 
STOP; 
? END JOB. 

The result of the bind is an object file named EXAMPLE/PROG. When executed, 
EXAMPLE/PROG generates the following output: 

ABCDEFGHIJKLMN0PQRSTUVWXY2 0123456789 
9876543210 ZYXUVUTSRQPONMLKJIHGFEDCBA 
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This section provides the information you need to compile, bind, and access an 
intrinsic file. For additional information about intrinsics, refer to the appropriate 
language manual. 

What Is an Intrinsic? 

An intrinsic is a program routine that performs common mathematical and other 
operations. An intrinsic file consists of standard system intrinsics such as SIN, 
SQRT, and formatting routines, as well as user- written intrinsics commonly 
referred to as ifistcUlation intrinsics. 

Although intrinsics can be written only in ALGOL, COBOL, and FORTRAN, almost 
any language that defines binding can access an intrinsic file. All compilers 
automatically recognize and access standard system intrinsics. COBOL and PL/I 
programs can automatically access installation intrinsics as well. FORTRAN and 
ALGOL programs must be compiled with the INSTALLATION compiler control 
option set in order to access installation intrinsics. 

Compiling Intrinsics 

When compiling an intrinsic, observe the following requirements: 

• You must set the INTRINSICS compiler control option for all compilations. 

• When compiling ALGOL and FORTRAN programs that access installation 
intrinsics, you must set the INSTALLATION compiler control option. 

• When compiling an intrinsic in COBOL, you cannot reference global items. 

• When compiling an intrinsic in DCALGOL, you can only reference other 
intrinsics or Master Control Program (MCP) items. 



Creating a Binder Input File 

To bind an intrinsic, you must create a Binder input file that includes the 
following: 

• A $SET INTRINSICS Binder control record. 

• A BIND statement specifying the source file or files for standard system 
intrinsics. Using the BIND = form of the BIND statement causes Binder to 
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look for all the standard system intrinsics whose names and intrinsic numbers 
are tabulated within Binder. 

• One or more BIND statements that specify the installation intrinsics. 

Once an intrinsic is bound into an intrinsic file, you cannot alter the intrinsic 
number, type of subprogram, or parameters by performing replacement binding. 
If you need to modify any of these items in an installation intrinsic, you must 
specify the necessary changes, and then bind the intrinsic into a new intrinsic 
file. To modify a standard system intrinsic, you must update the Binder internal 
tables and create a new intrinsic file. 



Intrinsic Specification 



Syntax 



Use the intrinsic specification construct with the BIND statement to bind 
installation intrinsics. 



<intrinsic specification> 

- <subprograin identifier> - > 
<intrinsic number pair> 

- <integer> - , - <integer> - 
<language list> 



- <intrinsic number pair> - <1anguage list> 



- ( 



ALGOL 



- COBOL - 

- DCALGOL - 

- FORTRAN - 
NEWP — 

L- PL/I — 



Explanation 

<intrinsic number Specifies an installation number and an intrinsic 

pair> number. The first integer of the intrinsic number pair 

metatoken specifies an installation number, which can 
range in value from 0 through 2046; however, numbers 
0 through 99 are reserved for system use. 

The second integer specifies an intrinsic number, which 
can range in value from 0 through 8191. 
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No two intrinsics within an intrinsic file can have the 
same intrinsic number pair. 

<language list> Specifies the compilers that are authorized to reference 

a given intrinsic. A referencing language is not 
necessarily the same language in which the intrinsic is 
written. For example, the DCALGOL language identifier 
allows a specified intrinsic to be accessed by the 
DMALGOL and DCALGOL compilers. 

Details 

Binder automatically binds standard system intrinsics that are referenced as 
EXTERNAL in a program. Thus, you do not need to specify such system intrinsics 
in a BIND statement. 

Example 

This example shows a Binder input file that is used to bind intrinsics. 

$ SET INTRINSICS 

BIND - FROM INTR/=; 

BIND MYSIN =101, 1 (ALGOL, FORTRAN) FROM INTL/=; 

BIND COFFEE = 102, 2 (COBOL) FROM POT; 

STOP; 
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Section 7 

Binding Programs That Access 
Databases 

You can bind programs that access Data Management System II (DMSII) or 
Semantic Information Manager (SIM) Databases. To do so, you must declare the 
database in the host program and meet the criteria discussed in this section. 

Note that the examples in this section illustrate the possible combinations in 
which the host program and the subprogram can declare a SIM database for 
binding. These examples are not complete and cannot be compiled as shown. 
Comments are placed within the examples to indicate portions of missing code. 

References made to compiler in the examples in this section refer to the language 
compiler used to compile the host program and the subprogram. 

Binding DIVISII Databases 

You can bind subprograms that access DMSII databases to host programs 
compiled with ALGOL, COBOL85, COBOL74, COBOL68, and PL/I compilers. 
Observe the following requirements: 

• The database code files must be compiled with a Mark 3.5 or later compiler. 

• You must declare the DMSII database as global in the host program. 

Binding SIIVI Databases 

You can bind subprograms that access SIM databases to host programs compiled 
in ALGOL, COBOL74, and Pascal. (Pascal programs can serve only as host 
programs.) You can bind subprograms that reference the following elements: 

• A database declared in the host program 

• An entity reference variable declared in the host program 

• A query variable declared in the host program 

Binder performs type checking of the variables for compatibility. 

For an explanation of SIM concepts and instructions for using SIM, refer to the 
A Series IvfoExec^ Administration Guide and the A Series IrtfoExec(S> Semantic 
Information Manager (SIM) Programming Guide. 



InfoExec is a trademark of Unisys Corporation. 
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SIM Data Types 

Binder recognizes three data types when binding programs that use SIM 
databases: the DMRECORD variable, the entity reference variable, and the query 
variable. Before binding programs, Binder verifies that these data types reference 
the same class in the same database. The three data types are as follows: 

• DMRECORD 

A DMRECORD is made up of fields that hold information retrieved from SIM. 
You can bind DMRECORDs to each other. 

• Entity reference variable 

An entity reference variable refers to an entity with the attributes of a given 
database class. 

The compiler queries SIM about this database class and gets information 
about the format of the entity reference variable. The format determines the 
number of words that are allocated for this variable. If a subprogram 
references an entity reference variable, the variable must be declared in the 
global declarations and must be preceded by the database declaration. 

• Query variable 

A query variable represents an active query and contains information about 
the state of a query. 

The compiler queries SIM when class information is required. The class 
information is stored in the binding information of the code file. 

If the subprogram declares the query variable in the global declarations, the 
database declaration must precede the query variable declaration. 

If the query variable is associated with a DMRECORD, the DMRECORD must 
be declared before the query variable. Binder verifies that the host program 
and the subprogram query variables reference the same database class or 
DMRECORD. 



Referencing a SIM Database 

You must declare a SIM database in the host program and in the subprogram. 
When the compiler encounters the database declarations, it generates a SIM , 
library template in the outer block of the host program and generates a SIM 
library template in the subprogram. These templates import all the library objects 
in the SIM system. 

Binder changes all code references of the SIM library objects in the subprogram 
to match the SIM library objects in the host program. The following example 
shows the SIM library template generated by the compiler and the SIM library 
objects in the subprogram that Binder will change to match those of the host 
program. 
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Example 

Host Program HI 



BEGIN 

SEMANTIC DATABASE UNIVDB: (INSTRUCTOR, STUDENT) ; 



(2.2) - FUNNY SIRW 

(2.3) - SUPPORT LIBRARY TEMPLATE 

(2.4) - LIBRARY TEMPLATE MARKER 

(2.5) - SUPPORT LIBRARY PROCEDURE 



(2.15) - SUPPORT LIBRARY PROCEDURE 



These lines of code for 
the SIM library template 
are generated by the 
compiler. 

Several support library 
procedures generated by 
the compiler are bound. 

Other data structures 
are generated by the 
compiler and placed here. 



PROCEDURE REPLACE_ME (R); 
(2. IB) - REPLACE-ME 
REAL R; 
EXTERNAL; 



OPEN UNIVDB; 

% Additional program statements 
% could be included here. 

DELETE STUDENT WHERE CURRENT(STUQ) « STU; 
REPLACEJ1E (10); 
CLOSE UNIVDB; 
END. 



Subprogram SI 

[REAL I.J; % Global 

SEMANTIC DATABASE UNIVDB: (INSTRUCTOR, STUDENT) ;] % declaration 

(2.4) - FUNNY SIRW % These lines of code for 

(2.5) - SUPPORT LIBRARY TEMPUTE % the SIM library template 

(2.6) - LIBRARY TEMPUTE MARKER % are generated by the 

% compiler. 

(2.7) - SUPPORT LIBRARY PROCEDURE % 

% Several support library 

% procedures generated by 

% the compiler are bound. 
(2,17) - SUPPORT LIBRARY PROCEDURE % 
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PROCEDURE REPLACE J1E (Rl); 
(2, ID) = REPUCE_ME 
REAL Rl; 
BEGIN 

DELETE INSTRUCTOR WHERE SALARY > Rl; 
END; 

In the preceding example, the host program, HI, declares a SIM database in the 
outer block and an external procedure, REPLACEl_ME, to be bound. The compiler 
builds the SIM library template. 

The subprogram SI declares REPLACEu_ME, which references the database. The 
compiler builds the SIM library template for the subprogram. However, the stack 
locations in the subprogram for the SIM library objects and the procedure do not 
match the stack locations for those elements in the host program. Binder fixes 
these code references in the subprogram so that they match those in the host 
program. For example. Binder changes the stack location (2,D) of the procedure 
REPLACE_ME in the subprogram to match the stack location (2,B) of the 
procedure REPLACE_ME in the host program. 



Referencing a SIM Entity Reference Variable in a Host Program 

In this example, the subprogram references an entity reference variable declared 
in the host program. The database must be declared before the entity reference 
declaration in the global declarations of the host program. 

Example 

Host Program H2 

BEGIN 

SEMANTIC DATABASE UNI VDB: (STUDENT); 
ENTITY REFERENCE STU_REF (STUDENT); 
(2,B) - STU_REF 

PROCEDURE REPLACEJ1E (R); 
(2,E) = REPLACE_ME 
REAL R; 
EXTERNAL; 

<rest of declarations> 

OPEN UNIVDB; 

<program statenients> 

DELETE STUDENT WHERE CURRENT (STUQ) - STU«REF; 
REPLACE_ME (10); 
CLOSE UNIVDB; 
END. 
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Subprogram S2 

[REAL I, J, K; % Global declaration 

SEMANTIC DATABASE UNIVOB: (STUDENT) ; % 
ENTITY REFERENCE STU_REF (STUDENT);] % 
(2,D) - STU_REF 

PROCEDURE REPUCE-ME (Rl); 
(2.10) = REPLACE_ME 
REAL RI; 
BEGIN 

DELETE STUDENT WHERE CURRENT(STUQ) - STU_REF; 
END; 

In this example, the host program, H2, declares the entity reference variable 
STU-REF. The compiler determines whether STUDENT is a valid database class 
and, if so, allocates the proper number of stack cells for it. The compiler also 
supplies class and size information about STU_REF in the binding information. 

Binder also verifies that STU_REF references the same class in the same 
database in both the host program and the subprogram. As an added check, 
Binder verifies the size of STU_REF. Binder fixes the code references in the 
subprogram so that all code references to STU_REF match those of the host 
program. 

Referencing a SIM Query Variable in a Host Program 

In this example, the subprogram references a query variable declared in the host 
program. The database and an optional DMRECORD must be declared before the 
query variable declaration in the global declarations. 

Example 

Host Program H3 

BEGIN 

SEMANTIC DATABASE UNIVOB: (STUDENT) ; 
QUERY STUQ (STUDENT); 
(2,B) - STUQ 

PROCEDURE REPLACE_NE (R); 
(2,C) « REPUCEJ1E 
REAL R; 
EXTERNAL; 
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<rest of (leclarations> 
OPEN UNIVD6; 

<prograni statements> 

DELETE STUDENT WHERE CURRENT (STUQ) = STU_REF; 
REPLACE_ME (10); 
CLOSE UNIVDB; 
END. 

Subprogram S3 

[REAL I, J, K; % 61 obaT declaration 

SEMANTIC DATABASE UNIVDB: (STUDENT) ; % 

QUERY STUQ (STUDENT);] % 
(2,D) = STUQ 

PROCEDURE REPLACE_ME (Rl); 
(2,10) = REPUCE_ME 
REAL Rl; 
BEGIN 

DELETE STUDENT WHERE CURRENT(STUQ) = STU_REF; 
END; 

In the preceding example, the host program, H3, declares the query variable 
STUQ. The compiler determines whether STUDENT is a valid database class and, 
if so, supplies information about STUQ in the binding information. The compiler 
verifies that STUQ declared in the host program and in the subprogram 
references the same class (or DMRECORD) in the same database. 

Binder fixes the code references in the subprogram so that all code references to 
the global query variable STUQ match those of the host program. 



Adding Query Variables as New Globais 

The following example ilUustrates how a query variable that does not exist in the 
host program can be declared in the global declarations portion of the 
subprogram. A database declaration must precede the query variable declaration. 
If the query variable is associated with a DMRECORD, the DMRECORD must be 
declared before the query variable. 

When a query variable is declared in this way. Binder adds the query variable as 
a new global item and alters all subprogram code references to the query variable 
to match the host program code references to that query variable. Locally 
declared query variables are unaffected by Binder. 
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Example 

Host Program H8 

BEGIN 

SEMANTIC DATABASE UNIVDB; 

PROCEDURE REPLACE_ME (R); 
(2,B) = REPLACEJiE 
REAL R; 
EXTERNAL; 

<rema1n1ng declarations> 

OPEN UNIVDB; 

<program statements> 
REPLACEJIE (10); 
CLOSE UNIVDB; 
END. 

Subprogram S8 

[REAL I, J, K; %G1oba1 declaration 

SEMANTIC DATABASE UNIVDB; 
QUERY STUQ (STUDENT);] 
(2,D) = STUQ 

PROCEDURE REPLACE_ME (Rl); 
(2,E) = REPLACEJiE 
REAL Rl; 
BEGIN 

DELETE STUDENT WHERE CURRENT (STUQ) = STU_REF; 
END. 

In the preceding example, the subprogram, S8, declares the query variable STUQ. 
STUQ is a SIM construct used for querying database information, which is the 
database class STUDENT in this example. The compiler determines if STUDENT 
is a valid database class and supplies information about STUQ in the binding 
information. The compiler also allocates STUQ as a new global for the host. 
Binder alters the subprogram code references to the global query variable STUQ 
to match the host program code references to that query variable. 

Referencing a SIM Database in a Pascai Host 

To create a host program, the Pascal program must declare an external module. 
The variables, procedures, functions, and databases of the host program become 
visible to an external subprogram if the following occurs: 

• These items are exported by host modules before the declaration of the 
external module. 

• These items are imported by the EXTERNAL module. 
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Refer to the Pascal Reference Manual, Volume 1 for more information about 
compiling modules in the Pascal host program. 

The following example shows a Pascal host program that accesses a SIM 
database. Appropriate Pascal syntax is used to enable modules to bind external 
modules (subprograms) written in other languages. The Pascal compiler creates a 
file titled, BINDERINPUT, which contains Binder instructions to bind the external 
modules. 

Two modules are declared in the example program: data— access and data-User. 
The data_access module defines the database and the SIM variables used in the 
program. The SIM variables are exported, which makes them available to other 
modules such as data— user. 

The data— user module is declared external. The export list of this module 
contains an ALGOL subprogram, named ALGOL_subroutine, to be bound. The 
data_user module imports all the interface identifiers from the data_access 
module, including the database and other variables. This makes the database and 
the variables visible to the external program. 

The implementation section of the data— access module imports the ALGOL 
subprogram, ALGOL— SUBROUTINE, and uses it in a function call. 

Example 

Host Program H4 

MODULE DATA_ACCESS INTERFACE 
(univdb: database, 

Mydict: DICTIONARY <FUNCTIONNAME = •39DATADICTI0NARY'>) ; 
export data_access (intq, stuq, univdb, ent_ref, dmrec, dostuff); 
from univdb import instructor, student; 
type stu_rec_type = record 

stu_no : integer; 

end; 

stu_rec = dmrecord (stu_rec_type); 
var intq : query (instructor); 

stuq : query (student); 

ent_ref : entityreference (student); 

dmrec : stu_rec; 
procedure dostuff; 
end; 

module data_user external; 

export ALGOL_external (ALGOL-Subroutine); 

Import data-access; 

function ALGOL-Subroutine: integer; 

end; 

module data_access implementation; 

import AL60L_external; 

var salary_increase : Boolean; 
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limres 
int 



: dmstatetype; 
: integer; 



procedure dostuff ; 
var i : integer; 
begin 

i := ALGOl—Subroutine; 

open(univdb, update); 

begintransaction; 

startinsert (intq); 

If salary_increase then 

assign (intq. salary, 50000); 

applyinsert (intq); 

close (univdb); 
end; {End DOSTUFF} 

end. {Module implementation} 

program p; {Main program} 

import data-access; 

begin 
dostuff; 

end; 
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Section 8 

Printing Binding Information 

You can compile a program so that it generates the binding information used to 
bind the code file to another code file. Binding information consists of a 
description of the elements in the code file, such as 

• The lex level and code segment location for each procedure 

• A description of the items in the local directory of each procedure, including 
variables and arrays and their characteristics 

• A description of the information in the global directory of a procedure 

• A description of the information in an external procedure 

• The identification of various other elements, including the block exit pointer, 
the first executable code segment, and the global stack size 

Generating Binding Information 

Language compilers differ slightly in the instructions they require to generate 
binding information. These differences are described in the following list: 

• ALGOL and FORTRAN 

A program compiled in ALGOL or FORTRAN will have binding information 
generated when the NOBINDINFO compiler control option is set to FALSE. 
The default setting is FALSE. 

• COBOL 

A program compiled in COBOL will have binding information generated if any 
of the following conditions exist: 

- Its lexical (lex) level is greater than 2. 

- It contains a procedure declared as EXTERNAL. 

- The BINDINFO compiler control option is set to TRUE. 

• FORTRAN?? 

A program compiled in FORTRAN?? will have binding information generated 
when the BINDINFO compiler control option is set to TRUE. 

• Pascal 

A program compiled in Pascal will have binding information generated when 
a module is declared as external in the program. 
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Using the PRINTBINDINFO utility 

You can print an analysis of the binding information of a bound or unbound code 
file by using a utility named SYSTEM/PRINTBINDINFO (hereafter referred to as 
the PRINTBINDINFO utility). The binding information for each separate 
procedure of a multiprocedure library file (an ALGOL, FORTRAN, or 
FORTRAN?? program compiled with the LIBRARY option set to TRUE) is 
analyzed and printed. A list of the identifiers in the separate procedures is 
written at the beginning of the printed output. 

You can start the PRINTBINDINFO utility from a WFL job or from a CANDE 

session. 

The WFL syntax for running PRINTBINDINFO is as follows: 

? BEGIN JOB PRINT/BINDER/INFO; 

RUN SYSTEM/PRINTBINDINFO; 

FILE CODE » <code file title>; 

FILE LINE « <line printer output file title>; 
? END JOB. 

The CANDE syntax for running PRINTBINDINFO is as follows: 

RUN $SYSTEM/PRINTBINDINFO; FILE CODE « <code file title>; 
FILE LINE = <line printer output file title> 

The <code file title> and <line printer output file title> constructs are used in 
both the WFL and the CANDE syntaxes. 

The <code file title> construct specifies the code file whose binding information 
is to be analyzed. Its default file characteristics are as follows: 

KIND=PACK, FAMILYNAME="DISK.'*, FILETYPE=8, INTMODE= SINGLE 

The <line printer output file title> construct specifies the output file created by 
PRINTBINDINFO when the LIST option is set. Its default file characteristics are 
as follows: 

KIND=PRINTER, INTMODE- EBCDIC, MAXRECSIZE=22 

Note: If you try to run PRINTBINDINFO on a codeJUe that does not contain 
binding information, the system generates an error message and 
terminates execution. 
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Example 

Consider the following ALGOL program: 

BEGIN 

INTEGER I; 

REAL ARRAY ARY [0:4,0:9] ; 
REAL PROCEDURE RP(A); 

VALUE A; BOOLEAN A; 
BEGIN 

INTEGER J; 
END RP; 

END. 

If this program is compiled and its code file is given the title 
OBJECT/EXAMPLE/1, then the following CANDE command can be used to run 
PRINTBINDINFO to print a complete analysis of the binding information of 
OBJECT/EXAMPLE/1 : 

RUN $SYSTEM/PRINTBINDINFO; FILE CODE = OBJECT/EXAMPLE/1 

The output produced by PRINTBINDINFO appears as follows: 

PROGRAM DESCRIPTION: 



PROCEDURE D I RECTORY ******************************************** 
PROCEDURE BL0CK#1; LEX LEVEL: H02; CBIT CODE SEGMENT H0003 
LOCAL DIRECTORY 

0001 VARIABLE (INTEGER) H(02,0002) I 

0002 ARRAY (REAL) H(02,0003) ARY 

NUMBER OF DIMENSIONS: 02 

0003 FUNCTION (REAL) H (02, 0004) RP 

PARAMETERS 

NUMBER OF PARAMETERS: 01 
VARIABLE (BOOLEAN) 
LIT48 POINTER FOR MAKING PCW: H(O003:0O07:3,LL=00) 
PROCEDURE RP; LEX LEVEL: H03; CODE SEGMENT H0005 

LOCAL DIRECTORY 

0004 VARIABLE (REAL) H (03, 0003) RP. VALUE 

0005 VARIABLE (BOOLEAN) H(03,0002) A 

0006 VARIABLE (INTEGER) H (03, 0004) J 
END OF PROCEDURE DIRECTORY ************************************* 

GLOBAL DIRECTORY ****************************** 

INTRINSIC (REAL) H(01,0004) ?007 

INTRINSIC (REAL) H(01,0006) ?010 

END OF GLOBAL DIRECTORY ************************ 

BLOCK EXIT POINTER: H(0003:0006:2, LL=02) 
FIRST EXECUTABLE CODE: H (0003: 0000:1, LL=02) 
POINTER TO END OF D2 STACK: H(0003: 0009:0, LL=00) 



0007 
0008 



8600 0304-000 



8-3 



Printing Binding Information 



GLOBAL STACK SIZE: 5 

SOFTWARE CONTROL WORD IMAGE: H800000001000 



NO EXTERNAL PROCEDURES. 

Printing Binding information for Specific Procedures 

You can select certain procedures and blocks, and items within those procedures 
and blocks for which you want to print the binding information. You make 
selections by using a SELECTIDS file. 

The SELECTIDS file consists of a list of one or more EBCDIC identifiers separated 
by one or more blanks. If a SELECTIDS file is present when PRINTBINDINFO is 
run, binding information is analyzed and printed for only the listed items. 

If an identifier appears in the SELECTIDS file, information about that identifier 
is printed only if one of the following conditions is true: 

• The identifier belongs to a procedure or block in the program. 

• The identifier is described in the program description outside the global 
directory and the own directory. 

• The identifier is described in the global directory. 

• The identifier is described in the own directory. 

• The identifier is described in the local directory of a procedure or block, and 
the identifier of that procedure or block also appears in the SELECTIDS file. 

For example, if identifier M is declared in procedure P, then information about M 
is printed only if both M and P appear in the SELECTIDS file. 

If identifier J is declared in the outer block of an ALGOL program, then 
information about J is printed only if both J and the identifier of the outer block 
appear in the SELECTIDS file. 

(The identifier of the outer block of an ALGOL program is BLOCKi^l for 
programs compiled with Mark 3.5 and later compilers and B.OOOO for programs 
compiled with compilers earlier than Mark 3.5.) 

The default characteristics for the SELECTIDS file are as follows: 

KIND=READER, INTMODE= EBCDIC, FILETYPE = 8 

To use a disk file for SELECTIDS, specify KIND=DISK when file-equating. 
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Example 

The following WFL job runs PRINTBINDINFO to analyze OBJECT/EXAMPLE/ 1, 
the ALGOL program shown in the previous example, but restricts the analysis by 
providing a SELECTIDS file: 

? BEGIN JOB RUN/PRINTBINDINFO; 
RUN SYSTEM/PRINTBINDINFO; 
FILE CODE = OBJECT/EXAMPLE/1; 
DATA SELECTIDS 
BL0CK#1 
ARY 
J 

? END JOB. 

The output produced by this job appears as follows: 

SELECTED IDENTIFIERS: 

BL0CK#1 

ARY 

J 



PROGRAM DESCRIPTION: 

PROCEDURE DIRECTORY 

PROCEDURE BL0CK#1; LEX LEVEL: H02; CBIT CODE SEGMENT H0003 
LOCAL DIRECTORY 

0001 ARRAY (REAL) H(02,0003) ARY 

NUMBER OF DIMENSIONS: 02 
END OF PROCEDURE DIRECTORY ************************************* 

GLOBAL DIRECTORY ****** 

END OF GLOBAL DIRECTORY ****** 



NO EXTERNAL PROCEDURES. 

In this output, no information is printed for J because J is described in the local 
directory of the procedure RP, and RP does not appear in the SELECTIDS file. 
Information about ARY was printed because ARY appears in procedure 
BL0CK#1, and BL0CK#1 appears in the SELECTIDS file. 



Output Options 

You can use the following three options to affect the format of the output from 
the PRINTBINDINFO utility. To enable one or more of these options, you must 
assign a negative value to the TASKVALUE attribute. To do this, set bit 46 of the 



8600 0304-000 



8-5 



Printing Binding Information 



TASKVALUE attribute to 1. In addition, you must set a bit for each specific 
option as indicated below. A list of the enabled options appears at the beginning 
of the printed output. 

DEBUG Prints binding information in unanalyzed as well as 

analyzed form. To enable the DEBUG option, set bit 0 
(zero) of the TASKVALUE attribute to 1. 

IGN0RE1.0CALDIR Prevents local directories from being analyzed and printed. 

To enable the IGNORELOCALDIR option, set bit 1 of the 
TASKVALUE attribute to 1. 



NOREFERENCES Prevents code references from being analyzed and printed. 

To enable the NOREFERENCES option, set bit 2 of the 
TASKVALUE attribute to 1. 



Example 

The following CANDE command causes PRINTBINDINFO to analyze the code file, 
OBJECT/TEST, with the options IGNORELOCALDIR and NOREFERENCES 
enabled: 

RUN $SYSTEM/PRINTBINDINFO; VALUE=^6; FILE CODE « OBJECT/TEST 
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Warning and Error Messages 



This appendix contains an alphabetical listing of the warning and error messages 
that you might encounter when using Binder and provides corrective action when 
applicable. 

COBIMA EXPECTED 

• This error message is given in the following situations: 

- In an INITIALIZE statement, the comma in the address couple is missing. 

- In a BIND statement of the form BIND <intrinsic specif ication>, the 
comma after the first integer of the intrinsic number pair is missing. 

A COMPILER ERROR WAS DETECTED AT BINDER LINE NUIMBER nnimmiiiii 

• Refer this problem to your Unisys Customer Service Representative. 
A <DIRECTORY SPECIFIER> IS NOT ACCEPTABLE HERE 

• This error results when a directory specifier appears in a HOST statement. 
A <FILE NODE> WAS EXPECTED IN THIS FILE NAME 

• There is an error in the format of the file name. 

A GLOBAL VARIABLE (THAT WAS REFERENCED FROM AN INTRINSIC 
BEING BOUND) COULD NOT BE FOUND. USE A BIND STATEMENT 

• An intrinsic being bound to an intrinsic file references a global variable that 

- Is not an MCP global item 

- Is not initialized to a correct address couple by an INITIALIZE statement 

- Does not already exist in the intrinsic file 

- Is not specified to be bound on a BIND statement 

A LEFT PARENTHESIS IS MISSING HERE 

• In an INITIALIZE statement, the left parenthesis at the beginning of the 
address couple is missing. 

A NEW GLOBAL VARIABLE BAAY NOT BE ADDED TO A HOST THAT IS A 
SUBPROGRAM WITH NO GLOBAL DECLARATIONS 
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• The host program is a subprogram that contains no global declarations. 
Binder does not allow a new global to be added to such a host in the course of 
binding a nested subprogram. 

A QUOTE MARK WAS EXPECTED 

• An identifier that begins with a quotation mark is missing the ending 
quotation mark. 

A RIGHT PARENTHESIS WAS EXPECTED HERE 

• This error is given in the following situations: 

- In an INITIALIZE statement, the right parenthesis at the end of the 
address couple is missing. 

- In a BIND statement of the form BIND <intrinsic specification>, the 
right parenthesis at the end of the language list is missing. 

- In a file specifier or directory specifier, the right parenthesis following 
the usercode is missing. 

A SEMICOLON WAS EXPECTED HERE 

• The semicolon (;) at the end of the Binder input statement is missing. 
A SUBPROGRAM IDENTIFIER WAS EXPECTED HERE 

• In a BIND statement, the word BIND is not followed by an identifier or an 
equal sign (=). 

A VALID INTEGER WAS EXPECTED HERE 

• This error is given in the following situations: 

- In an INITIALIZE statement, either the Hrst or second number of the 
address couple is not a valid integer. 

- In a BIND statement of the form BIND <intrinsic specif ication>, either 
the first or second number of the intrinsic number pair is not a valid 
integer. 

A VALID LANGUAGE IDENTIFIER WAS EXPECTED HERE 

• In a BIND statement of the form BIND <intrinsic specification>, an item in 
the language list is not a valid language identifier. 

AN ARRAY PARAMETER MUST BE DECLARED BEFORE THE 24TH 
PARAMETER 

• The procedure to be bound has more than 24 parameters, and an array was 
discovered after the 24th parameter. 

• Avoid this error by declaring arrays within the first 24 parameters. 
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AN ARRAY THAT WAS ADDED AS A NEW GLOBAL VARLABLE BIAD NO 
LENGTH SPECIFIED FOR IT 

• The array that was added as a new global array to the host program had no 
length specified for it. 

In ALGOL, this results from not declaring an upper bound for the array 
within the brackets used for declaring such global items for separate 
compilation. 

In COBOL, this message occurs when a new array is added to a host program 
by Binder. New global arrays are not allowed for COBOL binding. 

AN ENTRY POINT CANNOT BE ADDED AT OTHER THAN THE GLOBAL 
LEVEL 

• If a FORTRAN subprogram containing entry points is compiled at a lexical 
level higher than 3 and bound to a host program in which one of the entry 
point variables was not previously declared, an error results. The entry point 
would have to be added at the global level, which is incompatible with its 
execution level. 

• When binding a higher level subprogram containing entry points, declare all 
entry points directly within the program unit to which the subprogram is 
bound. 

AN INTERNAL BINDER ERROR HAS OCCURRED 

• Refer this problem to your Unisys Customer Service Representative. 

AN INTERNAL BINDER ERROR HAS OCCURRED—THE PROCEDURE 
DIRECTORY AND THE INFO TABLE ARE MISBAATCHED 

• Refer this problem to your Unisys Customer Service Representative. 

BINDER CONTROL OPTIONS BfAY NOT APPEAR IN THE MIDDLE OF A 
BINDER STATEBfENT 

• Binder control records can appear between Binder statements but cannot 
appear within a Binder statenient contained on more than one input record. 

BOUND CODE LEVEL CHANGED FROM rrJU TO nr.m. 

• This error message is given in the following situations: 

- You tried to bind a subprogram compiled with an earlier version of the 
compiler than that used to compile the host program or previously bound 
subprograms. 

- Binder is an earlier version than the bound programs. 
The bound code file is set to the earliest version found. 
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DUE TO THE ABOVE ERROR(S), THE BINDING OF THIS PROCEDURE IS 
DISCONTINUED 

• The definition of a subprogram within a subprogram file was found to be 
incompatible with the subprogram's definition in the host. The reason for the 
incompatibility was indicated by the error messages emitted prior to this 
message. 

Binder discontinues binding the procedure at this point, resets the error count 
back to the value it had before the start of binding the subprogram, and 
continues the binding process. The given subprogram is treated as if no 
attempt had been made to bind it. 

If two subprograms within the host program are known by the same identifier 
and Binder attempts to bind both occurrences of the identifier from the same 
subprogram, the definition of the separate subprogram probably would be 
incompatible with one of the occurrences, but might be compatible with the 
other occurrence. Thus, the subprogram would be bound correctly to its 
compatible occurrence, and the incompatible occurrence would not affect the 
bind in an adverse way. This result might have been the original intention of 
the user who did not realize that a subprogram identifier occurred twice 
within the host. 

<NAME> EXPECTED 

• This error is given when the following situations occur within a file specifier 
or directory specifier: 

- The usercode is not a valid name. 

- The family name is not a valid name. 

- The specifier does not begin with a valid name or the equal sign. 

- A right parenthesis, an asterisk, or a slash is not followed by a valid name 
or an equal sign. 

- A name is specified to be two quotation marks with no characters in 
between. 

FILE <FILENAME> NOT AVAILABLE 

• A BIND ? FROM <fUe> statement was issued and Binder did not find the 
file. 

FORTRAN77 SUBPROGRAMS BIAY NOT BE BOUND INTO A BfARK 3.6 
FORTRAN?? HOST 

• Compile the host program with a Mark 3.7 level or newer compiler. 

IN A CODE FILE THAT CANNOT RUN ON ANY MACHINE, A COMMON 
BLOCK CANNOT BE EXTENDED BECAUSE IT IS CODEFILE INITIALIZED 

• The FORTRAN?? host program was compiled with CODEFILEINIT set, and 
locations in the common block were initialized. A subprogram being bound 



A-4 



8600 0304-000 



Warning and Error Messages 



declared the common block to be longer than the common block in the host. 
Because the initial value of the common block was initialized within the code 
file, the common block could not be extended. 

IN THIS BIND STATEMENT, AN EQUAL SIGN WAS EXPECTED HERE 

• In this statement, the equal sign after the identifier is missing. 

BfARK nn CODE FILES MAY NOT BE BOUND; ONLY MARK mm, OR LATER 
CODE FILES MAY BE BOUND 

• You tried to bind a code file that was more than three system software 
releases old. The letters nn indicate the release level of the code file. The 
letters mm indicate the earliest release level of software that can be used 
with Binder, which is software that is three releases older than the current 
l6vel of Binder. 

MEMORY MODEL MISMATCH: THE HOST USES THE nnnnnnnit MODEL, 
THE SUBPROGRAM USES THE iinnnnnnnn MODEL. 

• The value of the MEMORY— MODEL option must be the same for a C host 
program and a C subprogram. 

NEW GLOBAL AND <OWN> VARIABLES CANNOT BE ADDED TO THE 
HOST 

• If the host is a NEW? program, new global variables and own variables 
cannot be added. 

NEW GLOBAL VARIABLES CANNOT BE ADDED WHILE BINDING SEGMENT 
1 OF THE MCP 

• While MCP segment 1 is being bound, new globals cannot be added to the 
MCP. 

OFFSET OF 4096 CANNOT BE REACHED FROM LEX LEVEL 2 

• The number of stack cells that can be referenced at lex level 2 cannot be 
increased, because A Series operators, such as NAMC and VALC, have a 
12-bit displacement field. Thus, 4095 is the maximum offset that can be 
referenced. 

• To avoid exceeding the maximum offset at lex level 2, limit the number of 
variables declared as GLOBAL or OWN to only those that must have a global 
address. 

ONLY MULUPROCEDURE FILES ARE ALLOWED IN UNIVERSAL BIND 
STATEMENT 

• One of the following two types of statements was given as input to Binder: 
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BIND = FROM A/B 

BIND P, Q, SUBR FROM A/B; 

In these examples, A/B is not a library or multiprocedure file. Because A/B 
contains only one subprogram, it should not be used in the above BIND 
statements. 

ONLY THE LAST BIND STATEMENT ENCOUNTERED WILL BE USED 

• If more than one BIND statement is found, the last statement entered is used. 

OUTPUTMESSA6E ARRAY NAMES MUST BE UNIQUE THROUGHOUT THE 
ENTIRE PROGRAM 

• Output message array names are an exception to the rules of scope for an 
identifier. They must be unique throughout the entire program. 

PL/I PROGRAMS MAY ONLY BE BOUND TO PL/I PROGRAMS 

• A subprogram compiled by the PL/I compiler can be bound only to host 
programs compiled by the PL/I compiler. 

REPLACEMENT BINDING IS NOT ALLOWED 

• If the host program is a NEWP program, only output message arrays or 
procedures declared as EXTERNAL can be bound. 

<lo> <LIBRARY OBJECT> REQUIRES LIBRARY <11> 

• Binder did not find the library <11> in the host program, so it did not bind 
the library object <lo>. This error can occur if the library names are 
different in the host program and the subprogram. 

• To match different names, include a USE statement in the primary input file. 
For the syntax and explanation of the USE statement, see Section 3. 

Refer this problem to your Unisys Customer Service Repriesentative if the 
preceding solution is not applicable. 

SINCE NO INTRINSIC NUMBER WAS GIVEN, THIS INTRINSIC CANNOT BE 
REFERENCED OUTSIDE OF THE INTRINSICS FILE 

• You did not specify an intrinsic number pair for a new intrinsic being added 
to an intrinsic file. The intrinsic can be called by other intrinsics within the 
file, but cannot be invoked from a user program. 

THE AREASIZE OF THE BOUND CODE FILE IS TOO SMALL. INCREASE IT 
BY SETTING THE AREASIZE FILE ATTRIBUTE DURING THE BIND 

• During the conclusion of intrinsic binding, Binder found that the area size of 
the bound code file was smaller than required. 

• Increase the area size of the bound code file by using the AREASIZE file 
attribute as shown in the following example: ^ 
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BEGIN JOB MAKE/INTRINSICS; 
BIND NEW/INTRINSICS WITH BINDER LIBRARY; 
BINDER FILE CODE (AREASIZE « 2016); 
BINDER DATA 
$ SET INTRINSICS 

BIND = FROM INTR/=; 

BIND MYINT = 101,1 (ALGOL, FORTRAN) FROM INTL/=; 
? ! END DATA 
END JOB. 

THE BIND STATEBIENT FOR THIS PROCEDURE WAS NOT USED -<EITHER 
THE ABOVE BIND STATEMENT(S) WERE OVERRIDDEN BY ANOTHER 
STATEBIENT, OR THE PROCEDURE IDENTIFIER DID NOT EXIST IN THE 
HOST AND WAS NOT CALLED BY ANY PROCEDURE BOUND IN.) 

• If a subprogram identifier specified in a BIND statement is not declared in the 
host program or otherwise encountered during the binding process, the 
subprogram is not bound. 

THE BINDER OPTION DEBUG HAS BEEN DEIMPLEMENTED. INSTEAD USE 
THE TEST AND DEBUG SYSTEM (TADS) 

• The Binder DEBUG option is no longer valid. 

• Use the Test and Debug System (TADS) appropriate to the program in error 
to identify the binding problem. 

THE BINDER WAS UNABLE TO BIND ONE OR MORE PROCEDURES BUT 
THE CODE FILE IS STILL EXECUTABLE 

• This warning message is given when Binder has been unable to bind one or 
more of the procedures declared as EXTERNAL or explicitly named in a BIND 
statement. The bound code file can be executed. However, if an attempt is 
made to execute an external subprogram that was not bound, the following 
error message is given: 

<identifier> NOT BOUND 

If Binder is unable to replacement bind a subprogram, the original 
subprogram remains in the bound code file. 

THE BINDER'S INTERNAL CONSTANT ARRAY HAS OVERFLOWED - THE 
BINDER'S CAPACITY HAS BEEN EXCEEDED 

• Refer this problem to your Unisys Customer Service Representative. 

THE BINDER'S INTERNAL INFO TABLE HAS OVERFLOWED - THE 
BINDER'S CAPACITY HAS BEEN EXCEEDED 

• Refer this problem to your Unisys Customer Service Representative. 
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THE CODEFILES CONTAIN DATA MANAGEMENT LEVELS THAT ARE 
INCOMPATIBLE AND CANNOT BE BOUND 

• This error message refers to the binding of DMSII databases. The host 
program and all subprograms that reference a DMSII database must all be 
compiled with the same level of DMSII software. 

THE COMMON BLOCK CANNOT BE EXTENDED FOR THIS HOST. YOU MUST 
RECOMPILE THE HOST 

• A subprogram tried to extend a global array by declaring it larger in the 
subprogram than in the host. The new size was too large to fit in the array 
declaration parameters of the host. This situation can occur only with hosts 
compiled before release 3.6. 

THE DECLARATION IN SUBPROGRAM MUST BE COMPATIBLE WITH THE 
DECLARATION IN HOST 

• The description of a library object in the subprogram is not compatible with 
the description of the same library object in the host program. This 
incompatibility can occur with mismatched parameter types or with 
mismatched by-reference or by-value usage. 

THE FORTRAN?? HEAP VECTOR EXCEEDS MAXIMUM LENGTH. 
RECOMPILE THE SEPARATE FILE WITHOUT THE »HEAP' OPTION 

• New heap vector entries in a FORTRAN?? subprogram would make the length 
of the heap vector exceed its maximum of 65,535. 

THE HOST AND THE SUBPROGRAM DO NOT HAVE THE SAME LIBRARY 
SHARINGCLASS 

• This error occurs if the subprogram and the host program being bound are 
libraries, but have a mismatched SHARINGCLASS. For example, the 
subprogram is a share-by-all library, whereas the host program is a private 
library. 

THE HOST CODE FILE WAS PRODUCED BY A PREVIOUS BIND. 
ADDITIONAL BINDING IS NOT ALLOWED 

• A bound C program cannot be used as the host of a subsequent bind. 
THE HOST FILE IS NOT AN INTRINSICS FILE 

• The INTRINSICS option has the value TRUE in Binder, but the host program 
is not an intrinsics file. 

THE HOST WAS COMPILED AT A LEXICAL LEVEL TOO HIGH 

• Compile the host program at lexical level 2 or 3. 
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THE IDENTIFIER OF THE SEPARATE PROCEDURE DOES NOT MATCH THE 
DECLARATION IN THE HOST 

• Binder was directed by a BIND statement to bind the given subprogram from 
a specific file. The subprogram identifier in the subprogram file does not 
match the declaration in the host. Binder generates this message and creates a 
USE statement that matches the two identifiers. Note that this situation 
cannot occur when binding from a specific library file or multiprocedure file. 

THE INITIALIZE STATEMENT IS LEGAL FOR INTRINSIC OR MCP BINDING 
ONLY 

• The INITIALIZE statement is legal only for intrinsic or MCP binding. 

THE INTERNAL BINDER ARRAY, CRIT_BLILJ^C, HAS OVERFLOWED - THE 
BINDER CAPACITY HAS BEEN EXCEEDED 

• Refer this problem to your Unisys Customer Service Representative. 

THE LIBRARY ATTRIBUTES IN THE SUBPROGRAM DIFFER FROM THE 
HOST. THE HOST UBRARY ATTRIBUTES WILL BE USED. 

• The subprogram and the host program have a different number of attributes 
or else the attributes do not match. You need not have attributes in the 
subprogram because the attributes of the host program are always used. 

THE MATCHING LIBRARY <NAME> COULD NOT BE FOUND IN THE HOST 

• Binder could not find the named library referenced by the library object. 

THE BIERGE OF THE TARGET LEVELS HAS RESULTED IN A CODE FILE 
THAT CANNOT BE RUN ON ANY MACHINE 

• Either the host program or previously bound subprograms have machine 
features not available for the target level of this subprogram, or this 
subprogram has machine features not available in the host program or 
previously bound subprograms. 

THE NUMBER OF ARRAY DIMENSIONS IN THE SUBPROGRAM DIFFERS 
FROM THE NUMBER OF DIBfENSIONS IN THE HOST 

• When an array is shared as a global item between two programs, it must be 
declared with the same number of dimensions in both programs. 

THE NUMBER OF INTERNAL BINDER FILES REQUIRED IS TOO GREAT - 
THE BINDER*S CAPACITY HAS BEEN EXCEEDED 

• The number of file declarations reserved by Binder for subprogram files has 
been exceeded. Each time Binder regresses to a previous level to bind a nested 
external subprogram, an additional subprogram file declaration is required. In 
addition, each library or multiprocedure file opened by Binder is left open 
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until all subprograms have been bound from it. Thus, if the number of library 
files is greater than the number of file declarations, this message results. 

• Refer this problem to your Unisys Customer Service Representative. 

THE NUMBER OF PARAMETERS IN THE SUBPROGRAM DIFFERS FROM 
THE NUMBER OF PARAMETERS IN THE HOST 

• For binding to occur, you must declare the same number of parameters in 
both the host program and the subprogram to be bound. 

THE OFFSET OF xxxx CANNOT BE REACHED FROM LEXICAL LEVEL xx 

• As the execution lex level of a subprogram increases, the offset that can be 
specified in a VALC or NAMC operator decreases. If a program or subprogram 
at a low lex level declares many variables, it is possible that a subprogram at 
a higher lex level will not be able to reference all of them. 

THE PROCEDURE THAT IS BEING PASSED AS A PARAMETER WAS NOT 
DECLARED IN A FORMAL DECLARATION 

• When the parameters expected by a formal procedure are specified in a 
formal declaration by both the program unit passing the procedure as an 
argument and the subprogram receiving the procedure as a parameter, then 
no parameter checking for the formal procedure is performed at execution 
time. This error results when either the receiver or caller specifies the 
procedure formally, but the program unit passing or receiving the formal 
procedure does not contain a formal declaration of the procedure. 

THE RESERVED WORD 'FOR* WAS EXPECTED HERE 

• In a USE statement, the word FOR after the first identifier is missing. 
THE RESERVED WORD *FROM' WAS EXPECTED HERE 

• In a BIND statement that begins with BIND =, the word FROM is missing 
after the equal sign (=). 

THE RESERVED WORD *IS* WAS EXPECTED HERE 

• In a HOST statement, the word IS is missing after the word HOST, 

THE RESULTING CODE FILE WILL RUN ON A MORE RESTRICTED SET OF 
MACHINES THAN THE HOST 

• This warning message is given when a subprogram must run on a more 
restricted set of computers than the host program. The resulting bound code 
file will run only on the more restricted set of computers. 
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THE SDF FORM LIBRARY APPUCATION RECORD DESCRIPTION IN THE 
HOST DID NOT MATCH THE SUBPROGRAM. 

• SDF form record libraries in the host program and the subprogram are 
different versions, although they have identical names. This might indicate 
that one or more forms in the form library were altered between compilation 
of the host program and the subprogram. 

• Recompile the host program and the subprogram. 

THE SUBPROGRAM IDENTIFIER CONTAINED TOO BIANT QUALIFIERS 

• The subprogram identifier contains more qualifiers (OF <i>dentifier> 
clauses) than are legal. 

THERE ARE TOO MANY ADDRESSED PROCEDURES 

• The number of addressed C functions exceeds the limits of Binder. 

THERE ARE TOO MANY CALLS TO FORBIAL OR ADDRESSED PROCEDURES 

• The number of calls to C functions through pointers exceeds the limits of 
Binder. 

THERE HAS BEEN A COMPILER ERROR. THE COMPILER EMITTED A 
BRANCH OPERATOR WITH AN OFFSET THAT IS TOO LARGE FOR THE 
LEXICAL LEVEL D2 

• Refer this error to your Unisys Customer Service Representative. 

THERE HAS BEEN A COMPILER ERROR. THE COMPILER EMITTED TOO 
MANY BRANCHES IN THE LEXICAL LEVEL D2 

• Refer this error to your Unisys Customer Service Representative. 

THERE IS A MISMATCH IN THE PARAMETER TYPE. IT IS BEING PASSED 
BY-NAME AND SHOULD BE PASSED BY-VALUE OR VICE VERSA 

• This message is given in the following situations: 

- During the binding of an exported procedure, the host program declares a 
parameter by value, and the subprogram declares it by name, or vice 
versa. 

- During ALGOL-ALGOL, COBOL-COBOL, or ALGOL-COBOL binding, the 
host program declares a parameter by value, and the subprogram declares 
it by name, or vice versa. 



8600 0304-000 



A-11 



Warning and Error Messages 



THERE IS A MISMATCH IN THE ROW SIZE OF THE HEAP (POSSIBLY 
CAUSED BY DIFFERENT LONGUBHTS): THE SIZE IN THE HOST = nimn, 
THE SIZE IN THE SUBPROGRAM » nnnn. 

• The value of the LONGLIMIT compiler control option must be the same for a 
C host program and a C subprogram. 

THERE IS A MISMATCH IN THE SIM CLASS INFORMATION. THE 
INTERNAL VALUE IN THE HOST = <VALUE>. THE INTERNAL VALUE IN 
THE SUBPROGRAM = <VALUE>. 

• The CLASSINFOs of the SIM entity reference variable, entity reference array, 
or query variable used in the host program are different from those used in 
the subprogram. This error occurs when items with the same name are 
declared with different field sizes. 

THERE IS A MISMATCH WITH THE (SIM) SEMANTIC QUALIFICATION. 
THE NAME IN THE HOST » <NAME>. THE NAME IN SUBPROGRAM » 
<NAME>. 

• The database ID used to qualify the SIM entity reference variable, entity 
reference array, or query variable for the host program is different from the 
ID used for the subprogram. This error message can result if you tried to bind 
a host program and a subprogram compiled with different SIM databases. 

THERE IS AN INCOMPATIBILITY IN THE ARRAY LOWER BOUNDS 
SPECIFICATION 

• This error message results when Binder detects that a subprogram expects 
lower bounds for an array and they are not passed, or a subprogram does not 
expect lower bounds and is called with lower bounds passed to it. 

FORTRAN and FORTRAN?? always pass an array descriptor and an offset. 

COBOL rarely passes an offset, although it accepts and passes an offset if the 
WITH LOWER BOUNDS clause is used. However, the offset value itself is 
ignored in calculating subscripts within the COBOL subprogram. 

In ALGOL, the user can specify whether the array parameter is passed with 
lower bounds. 

THERE IS AN INCORRECT NUMBER OF ADDRESS COUPLES DECLARED 
FOR THIS VARIABLE 

• A PL/I structure of another variable type has a number of address couples 
associated with it, in accordance with the way it is declared in the program 
unit. This error occurs when two program units reference the same variable 
with a different number of address couples, indicating an incompatibility in 
the declarations within the separate program units. 

THERE WERE NO SUBPROGRAMS BOUND TO THE HOST 

• No subprograms were bound to the host program during the binding process. 
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THIS BINDER OPTION IS NOW OBSOLETE AND WILL BE IGNORED 

• The Binder option you tried to use is obsolete. 

THIS CODE FILE IS THE RESULT OF A PREVIOUS BIND AND IS SUITABLE 
AS A HOST ONLY 

• The resultant code file from a previous bind cannot be bound to another host. 
Such a file may be used only as a host program in subsequent binds. 

THIS CODE FILE USES AN UNRECOGNIZABLE MEMORY MODEL 

• Refer this error to your Unisys Customer Service Representative. 
THIS FILE CANNOT BE ACCESSED BY THE BINDER 

• Binder is unable to access this file. 
THIS FILE IS NOT A CODE FILE 

• Check to make sure that the file title is complete and that a directory is not 
specified by the title. 

THIS ITEM DEFINITION HAS ALREADY BEEN SEEN. ONLY ONE 
NON-EXTERNAL DECLARATION IS ALLOWED. 

• The same variable or function is exported from more than one C subprogram 
or C host program. 

THIS ITEM IS A COPY OF TWO OR MORE DIFFERENT ITEMS 

• Refer this error to your Unisys Customer Service Representative. 
THIS ITEM WAS INITIALIZED IN TWO OR MORE DECLARATIONS 

• AC variable, array, or structure can be initialized only once. Binder has 
found an initialization in more than one C subprogram or C host program. 

THIS NEW GLOBAL VARIABLE HAS BEEN ADDED TO THE HOST 

• This is a warning message that indicates that a variable referenced in the 
subprogram does not exist in the host. Binder adds the variable to the host 
program at the global level. 

THIS NUMBER IS TOO LARGE 

• In an intrinsic number pair, either the first integer has a value greater than 
the largest possible installation number or the second integer has a value 
greater than the largest possible intrinsic number. 
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THIS IS A MISSPELLED CONTROL OPTION 

• The specified compiler control option is not a valid Binder compiler control 
option. Binder recognizes only a specific set of compiler control options. 
Binder does not recognize user options. 

THIS IS AN ILLEGAL <FAMILY NAME> 

• The family name in a file specifier or directory specifier contains invalid 
characters. Valid characters are A through Z and 0 (zero) through 9. 

THIS IS AN ILLEGAL IDENTIFIER 

• This error is given in the following situations: 

- In a Binder control record, the item following the dollar sign ($) is not of 
identifier format. 

- In a BIND statement, an item following OF in a subprogram identifier is 
not an identifier. 

- In an EXTERNAL statement, either the item at the beginning of a 
subprogram identifier or an item following OF in a subprogram identifier 
is not an identifier. 

- In an INITIALIZE statement, the item following INITIALIZE or following a 
comma (,) is not an identifier. 

- In a USE statement, the item following USE or FOR or the item following 
OF in the subprogram identifier is not an identifier. 

THIS IS AN INCORRECT INTRINSIC NUMBER BECAUSE ANOTHER 
INTRINSIC HAS THE SAME NUMBER 

• Two intrinsics within the same intrinsic file cannot have the same intrinsic 
number pair. 

THIS IS AN INCORRECT INTRINSIC NUMBER BECAUSE THE SAME 
INTRINSIC IDENTIFIER ALREADY EXISTS WITH A DIFFERENT NUMBER 

• An intrinsic with the same identifier already exists within the intrinsic file. 
The existing intrinsic has an intrinsic number pair different from that 
specified for the intrinsic being bound. 

THIS IS AN INVALID DATA DICTIONARY INVOCATION OR USAGE LIST 

• Refer this problem to your Unisys Customer Service Representative. 
THIS IS NOT A VALID BINDER STATEMENT 

• The input to Binder is not one of the valid Binder statements. 
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THIS OBJECT CODE FILE HAS NO BINDER INFORMATION 

• The file cannot be used for binding, either as a host program or as a 
subprogram. The option NOBINDINFO may have been set during the file's 
creation, or the respective compiler may have determined that the file 
contained no external references, so it did not require binding. 

THIS PROCEDURE CANNOT BE PASSED BETWEEN THESE TWO 
LANGUAGES 

• A procedure cannot be passed as a parameter from the language in which the 
procedure call is written to the language in which the procedure declaration 
is written. 

THIS PROCEDURE WAS NOT FOUND IN THE MULTIPROCEDURE FILE(S) 

• Binder was unable to find the subprogram within the library files designated 
in the BIND statement. The subprogram is left in the host program in its 
present form, and binding of other subprograms continues. 

THIS PROGRAM UNIT WAS COMPILED AT A LEXICAL LEVEL 
INCOMPATIBLE WITH THE LEXICAL LEVEL IN THE HOST. RECOMPILE 
USING THE OPTION $ SET LEVEL N 

• The given subprogram was compiled at a lex level incompatible with its 
execution lex level within the host. 

• Recompile the subprogram with the correct execution lex level by using the 
LEVEL option of the compiler. 

THIS PROGRAM UNIT IS SUITABLE AS A HOST PROGRAM ONLY, SO IT 
CANNOT BE BOUND INTO ANOTHER HOST 

• The designated subprogram file is actually a host program or main program. 
You cannot bind a host program to another host program. 

THIS VARIABLE TYPE CANNOT BE ADDED TO THE HOST 

• A variable referenced in a subprogram does not exist in the host. Usually 
Binder adds the variable to the host program. However, Binder is incapable of 
adding the following types of variables to a host: 

DATA BASE 

FORMAT 

LABEL 

LIBRARY 

LIST 

PICTURE 

SDF form record libraries 
Switch-type items 
TRANSACTION BASE 
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TO ADD A NEW LIBRARY OBJECT, LIBRARY <NAME> MUST BE 
COMPILED WITH A MARK 3.8 OR LATER COMPILER 

• To add a new library object, the host program must be compiled with a Mark 
3.8 or later version of the compiler. 

TOO MANY ENTRIES— INCREASE MAXENTRIES 

• Refer this problem to your Unisys Customer Service Representative. 
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Appendix B 

Using Binder Control Record Options 



You can control the manner in which Binder processes the subprogram file and 
the host program file by including Binder control records in the WFL job or 
CANDE file used to execute Binder. In each Binder control record, you include 
one or more Binder options. These options allow you to 

• Determine the content of printed output 

• Determine whether error messages get sent to the ERRORS file and get 
printed 

• Indicate whether a host file is required 

• Determine whether lineinfo and bindinfo are included in the code file 

• Determine whether a bound subprogram array is resized to match the host 
program array 

• Enable intrinsic binding 

• Prevent the code file from being locked when Binder cannot locate a 
subprogram 

• Temporarily suspend binding when a subprogram is not available 

Binder Control Record Format 

A Binder control record is identified by a dollar sign ($) in the first column of the 
record. Binder options follow the dollar sign in the succeeding columns through 
column 72. A percent sign (%) appearing in any column from 2 through 72 of a 
Binder control record indicates that the remaining columns of the record are to be 
ignored by the Binder. Binder control records can occur at any point in the Binder 
input file. 

There are two formats for including options in Binder control records. Syntax 1 
allows you to specify options that are effective throughout the binding process. 
Syntax 2 allows you to assign the value TRUE to certain options for the duration 
of the binding of specific subprograms. 

Syntax 1, Version A 



- $ 



p RESET -r-p 
L SET 1 L 



<B1nder opt1ons> —I 
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Syntax 1, Version B 
(4— 



- $ 



<Binder opt1ons> 



- RESET -H 

- SET - 

<Binder opt1ons> 
4— — 



_ CODE — 

- CODEN 

- ERRLIST 

- ERRORLIST 

- HOST 

- INTRINSICS — 

- LINEINFO 

- LIST 

- MAP 

- NOBINDINFO — 

- SEGS 

- STACK 

- STRICT 

- TIME 

- USEHOSTSIZE - 

- WAIT 

- WARN — 

Explanation 



Syntax 1 lets you specify Binder options that are effective throughout the 
binding process. Syntax 1 has two versions, A and B. 

Version A 

The Binder control record contains a dollar sign ($), followed by either SET or 
RESET, followed by one or more Binder options. If the action is SET, the named 
options are assigned a value of TRUE. If the action is RESET, the named options 
are assigned a value of FALSE. 
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If you do not name any options, all options are set or reset according to the 
action you specify. 

Example 

$ SET CODE STACK LIST 
$ RESET SEGS 

Version B 

The Binder control record contains a dollar sign ($) followed by one or more 
Binder options. SET and RESET are not used to indicate values of TRUE or 
FALSE. Rather, the named options are assigned a value of TRUE, and the 
unnamed options are assigned a value of FALSE, If the control record contains a 
dollar sign and no options, Binder ignores the record. (Note that ERRORLIST 
(ERRLIST), LINEINFO, and STRICT cannot be used in this syntax, so they assume 
their default values.) 

Example 

$ CODE STACK LIST 



Syntax 2 



- $ - <identifier> 



CODE 

- CODEN 

- LIST 

- MAP - 

- SEGS 

- STACK 

- WAIT 
WARN 



Explanation 

Syntax 2 lets you set certain options to TRUE for the binding of a specified 
subprogram. All named options are assigned a value of TRUE. All unnamed 
options are assigned a value of FALSE. 

The options assume the assigned values only during the binding of the 
subprogram specified by the identifier. Once the subprogram is bound, all options 
are restored to their previous values. For any option, the last setting in a control 
record of Syntax 1 takes precedence over all other settings. 

You can include only one subprogram identifier in each Binder control record. 
You must include one or more Binder options after the identifier. 
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Example 

$ PROCEDUREl CODE WAIT WARN 
For information about identifiers, see Section 2. 

Binder Options 

Binder options are discussed in alphabetical order in Table B-1: 



Table B-1. Binder Control Record Options 



Option 


Default Value 


Function 


CODE 


False 


Indicates whether the resultant code file will 
be printed in hexadecinfial form 


CODEN 


False 


Indicates whether the input code files will be 
printed in hexadecimal form 


ERRORLIST 


False 

(True for binds Initiated by 
CANDE) 


Indicates whether Binder will write error 
messages to the file titled, ERRORS. If 
Binder Is initiated from WFL. ERRORS is a 
printer file. If Binder is initiated from CANDE, 
ERRORS is a remote file, and messages are 
written to the remote station that Initiated 
the bind. (ERRORLIST is the preferred 
synonym for ERRLIST.) 


ERRLIST 


False 

(True for binds initiated by 
CANDE) 


See the preferred synonym, ERRORLIST. 


HOST 


False 


Indicates whether a host file is required. 
When the INTRINSICS options is FALSE, a 
host file is always required, and the HOST 
option has no effect. When the HOST option 
is TRUE and the INTRINSICS option is TRUE, 
a host file is required and is used for intrinsic 
binding. When the HOST option is FALSE and 
the INTRINSICS options is TRUE, a host file 
is not required and is not used. 


INTRiNSICS 


False 


Indicates whether an intrinsic file will be 
created or intrinsic binding will be enabled. 
When FALSE, the INTRINSICS option can still 
create an intrinsic code file if the host file is 
the object file of a previous intrinsic bind. If 
the INTRiNSICS option is FALSE, a host file 
is always required and the HOST option has 
no effect. 
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Table B-1. Binder Control Record Options (cont.) 



Option 


Default Value 


Function 


LINEINFO 


True 


Indicates whether the resulting code file will 
contain all LINEINFO encountered in the host 
and subprogram files. 


LIST 


True 

(False for binds irtitlated by 
CANOE) 


Indicates whether input records, identifiers 
and their address couples, and BEGIN 
BINOING and ENO BINDING messages will 
be printed. 


MAP 


False 


Indicates whether the address couples of all 
identifiers in the resultant code will be 
printed, both in alphabetical order by 
identifier and in address couple order. (The 
MAP option is the preferred synonym for the 
STACK option.) 


NOBINDINFO 


False 


Indicates whether the Binder will purge all 
Binder information from the resultant code 
file. The resultant code file cannot then be 
used as a host for a subsequent bind if the 
value of NGBINOINFO is TRUE. 


SE6S 


True 

(False for binds initiated by 
CANOE) 


Indicates whether the segment dictionary 
changes will be printed. Assigning a value to 
the LIST option causes the same value to be 
assigned to the SEGS option. 


STACK 


False 


See the preferred synonym, MAP. 


STRICT 


False 

(True for MCP binds) 


Indicates whether the resultant code file will 
be locked if a subprogram specified in a 
BIND statement is not bound. When FALSE, 
the code file is locked. 


TIME 


False 


Indicates whether header and trailer 
information for the bind will be printed. 
Because the information is printed when LIST 
is TRUE, the value of TIME is significant only 
when LIST is FALSE. 


USEHOSTSIZE False 


Indicates whether an array global to a bound 
subprogram is resized to the size of its 
corresponding array in the host. If the 
USEHOSTSIZE option is not set (FALSE), the 
larger array size from either the host or the 
subprogram is used. 
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Table B-1. Binder Control Record Options (cent.) 



Option 


Default Value 


Function 


WAIT 


False 


Indicates whether Binder will suspend the 
binding process if a specified subprogram file 
is not present. Upon suspension, the operator 
is allowed to make the file present, to 
terminate the Binder, or to enter the OF 
(Optional File) or FA (File Attribute) ODT 
command. Any OF or FA command applies to 
that file only. Subsequent nonpresent files 

nanin raiicp thp Rinripr fn ciicnAnri hinriino 

For more information about the OF and FA 
commands, refer to the System Commands 
Reference Manual. 


WARN 


True 

(False for binds initiated by 
CANDE) 


Indicates whether warning messages will be 
printed upon the occurrence of certain 
conditions. When WARN is FALSE, these 
warning messages are suppressed. Assigning 
a value to the LIST option causes the same 
value to be assigned to the WARN option. 
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Understanding Railroad Diagrams 



What Are Railroad Diagrams? 



Railroad diagrams are diagrams that show you the rules for putting words and 
symbols together into commands and statements that the computer can 
understand. These diagrams consist of a series of paths that show the allowable 
structure, constants, and variables for a command or a statement. Paths show the 
order in which the command or statement is constructed. Paths are represented 
by horizontal and vertical lines. Many railroad diagrams have a number of 
different paths you can take to get to the end of the diagram. For example: 



— REMOVE 



- SOURCE 

- OBJECT 



If you follow this railroad diagram from left to right, you will discover three 
acceptable commands. These commands are 

• REMOVE 

• REMOVE SOURCE 

• REMOVE OBJECT 



If all railroad diagrams were this simple, this explanation could end here. 
However, because the allowed ways of communicating with the computer can be 
complex, railroad diagrams sometimes must also be complex. 

Regardless of the level of complexity, all railroad diagrams are visual 
representations of commands and statements. Railroad diagrams are intended to 

• Show the mandatory items. 

• Show the user-selected items. 

• Present the order in which the items must appear. 

• Show the number of times an item can be repeated. 

• Show the necessary punctuation. 



To familiarize you with railroad diagrams, this explanation describes the 
elements of the diagrams and provides examples. 

Some of the actual railroad diagrams you will encounter might be more complex. 
However, all railroad diagrams, simple or complex, follow the same basic rules. 
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They all consist of paths that represent the allowable s|:ructure, constants, and 
variables for commands and statements. 

By following railroad diagrams, you can easily understand the correct syntax for 
commands and statements. Once you become proficient in the use of railroad 
notation, the diagrams serve as quick references to the commands and 
statements. 

Constants and Variables 

A constant is an item that cannot be altered. You must enter the constant as it 
appears in the diagram, either in full or as an allowable abbreviation. If a 
constant is partially underlined, you can abbreviate the constant by entering only 
the underlined letters. In addition to the underlined letters, any of the remaining 
letters can be entered. If no part of the constant is underlined, the constant 
cannot be abbreviated. Constants can be recognized by the fact that they are 
never enclosed in angle brackets (< >) and are in uppercase letters. 

A variable is an item that represents data. You can replace the variable with data 
that meets the requirements of the particular command or statement. When 
replacing a variable with data, you must follow the rules defined for the 
particular command or statement. Variables appear in railroad diagrams enclosed 
in angle brackets (< >). 

In the following example, BEGIN and END are constants, and <statement list> is 
a variable. The constant BEGIN can be abbreviated since it is partially 
underlined. Valid abbreviations for BEGIN are BE, BEG, and BEGI. 

— BEGIN — <statement list>— END 1 



Constraints 

Constraints are used in a railroad diagram to control progression through the 
diagram. Constraints consist of symbols and unique railroad diagram line paths. 
They include 

• Vertical bars 

• Percent signs 

• Right arrows 

• Required items 

• User-selected items 

• Loops 

• Bridges 
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A description of each item follows. 

Vertical Bar 

The vertical bar symbol 0) represents the end of a railroad diagram and indicates 
that the command or statement can be followed by another command or 
statement. 

— SECONDWORD — ( — orithmetic expression>— ) 1 

Percent Sign 

The percent sign (%) represents the end of a railroad diagram and indicates that 
the command or statement must be on a line by itself. 

_ STOP ■■ % 

RIgilt Arrow 

The right arrow symbol (>) is used when the railroad diagram is too long to fit 
on one line and must continue on the next. A right arrow appears at the end of 
the first line, and another right arrow appears at the beginning of the next line. 

— SCALERIGHT — ( — orithmetic express1on> — , ^ 

>-<arithmetic expression>— ) 1 

Required Items 

A required item can be either a constant, a variable, or punctuation. A required 
item appears as a single entry, by itself or with other items, on a horizontal line. 
Required items can also exist on horizontal lines within alternate paths or nested 
(lower-level) diagrams. If the path you are following contains a required item, 
you must enter the item in the command or statement; the required item cannot 
be omitted. 

In the following example, the word EVENT is a required constant and 
<identifier> is a required variable: 

— EVENT — <identifier> — 1 

User-Selected items 

User-selected items appear one below the other in a vertical list. You can choose 
any one of the items from the list. If the list also contains an empty path (solid 
line), none of the choices are required. A user-selected item can be either a 
constant, a variable, or punctuation. In the following railroad diagram, the plus 



8600 0304-000 



C-3 



Understanding Railroad Diagrams 



sign (+) or minus sign (— ) can be entered before the required variable 

< arithmetic expression>, or the symbols can be disregarded because the diagram 

also contains an empty path. 



-orithmetic expression>- 



Loop 



Bridge 



A loop represents an item or a group of items that you can repeat. A loop can 
span all or part of a railroad diagram. It always consists of at least two 
horizontal lines, one below the other, connected on both sides by vertical lines. 
The top line is a right-to-left path that contains information about repeating the 
loop. 

Some loops include a return character. A return character is a character — often a 
comma (,) or semicolon (;) — required before each repetition of a loop. If there is 
no return character, the items must be separated by one or more blank spaces. 



— <field value>-^ 



Sometimes a loop also includes a bridge, which is used to show the maximum 
number of times the loop can be repeated. The bridge can precede the contents of 
the loop, or it can precede the return character (if any) on the upper line of the 
loop. 

The bridge determines the number of times you can cross that point in the 
diagram. The bridge is an integer enclosed in curved lines (•'' ). Not all loops 
have bridges. Those that do not can be repeated any number of times until all 
valid entries have been used. 

In the first bridge example, you can enter LINKAGE or RUNTIME no more than 
two times. In the second bridge example, you can enter LINKAGE or RUNTIME 
no more than three times. 



LINKAGE -j 
L RUNTIME J 



C-4 



8600 0304-000 



Understanding Railroad Diagrams 



|4— /2> 

' [ LINKAGE -pJ 1 

L RUNTIME J 

In some bridges, an asterisk (*) follows the number. The asterisk means that you 
must cross that point in the diagram at least once. The maximum number of times 
that you can cross that point is indicated by the number in the bridge. 

i . 1 

1-/2*\- LINKAGE -pi 1 

RUNTIME J 

In the previous bridge example, you must enter LINKAGE at least once but no 
more than twice, and you can enter RUNTIME any number of times. 

The following table illustrates the constraints used in railroad diagrams. 



Symbol 


Explanation 


1 


Vertical bar. Indicates that the command or statement can be followed by another 
command or statement. 


_ % 


Percent sign. Indicates that the command or statement must be on a line by itself. 


— ^> 

> 


Right arrow. Indicates that the diagram occupies more than one line. 


— <required> — 


Required item. Indicates the constants, variables, and punctuation that must be 
entered in a command or statement. 




- YES - 

- NO — 




User-selected items. You select the item or items to include. 




4 j 




Loop. Indicates that an item or group of items can be repeated. 




f 1 




Bridge. Indicates the maximum number of times a loop can be repeated. 



Following the Paths of a Railroad Diagram 

The paths of a railroad diagram lead you through the command or statement 
from beginning to end. Some railroad diagrams have only one path, while others 
have several alternate paths. The following railroad diagram indicates there is 
only one path that requires the constant LINKAGE and the variable <linkage 
mnemonic>: 
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— LINKAGE — <linkage mnemonic) 1 

Alternate paths provide choices in the construction of commands and statements. 
Alternate paths are provided by loops, user-selected items, or a combination of 
both. More complex railroad diagrams can consist of many alternate paths, or 
nested (lower-level) diagrams, that show a further level of detail. 



For example, the following railroad diagram consists of a top path and two 
alternate paths. The top path includes an ampersand (&) and the constants that 
are user-selected items in the vertical list. These constants are within a loop that 
can be repeated any number of times until all options have been selected. The 
first alternate path requires the ampersand followed by the required constant 
ADDRESS. The second alternate path requires the ampersand followed by the 
required constant ALTER and the required variable <new value>. 



— & 



TYPE - 
ASCII 
BCL - 



- DECIMAL - 

- EBCDIC — 

- HEX — 



1- OCTAL 
I- ADDRESS — 



ALTER — <new valuer 



Railroad Diagram Examples with Sample input 

The following examples show five railroad diagrams and possible command and 
statement constructions based on the paths of these diagrams. 

Example! 



— LOCK — ( — <file identifier>— ) 

Sample Input 

LOCK (Fl) 

LOCK (FILE4) 

LOCK is a constant and cannot be altered. Because no part of the word is 
underlined, the entire word must be entered. The parentheses are required 
punctuation, and Fl and FILE4 are sample file identifiers. 
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Example 2 

<open stateinent> 
_ OPEN -, 



■<database naiiiev 



- INQUIRY - 

- UPDATE — 



Sample Input 

OPEN DATABASEl 



The constant OPEN is followed by the variable DATABASEl, which is a database 
name. The railroad diagram shows two user-selected items, INQUIRY and 
UPDATE. However, because there is an empty path (solid line), these entries are 
not required. 



OPEN INQUIRY DATABASEl 



The constant OPEN is followed by the user-selected constant INQUIRY and the 
variable DATABASEl. 

OPEN UPDATE DATABASEl 



The constant OPEN is followed by the user-selected constant UPDATE and the 
variable DATABASEl. 



Example 3 



<generate statefflent> 
— GENERATE — esubseta 



NULL 



subset>- 



ANO -r-<subset3 

- OR — 

— + — 



Sample Input 
GENERATE Z - NULL 

The GENERATE constant is followed by the variable Z, an equal sign (»), and the 
user-selected constant NULL. 
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GENERATE Z » X 



The GENERATE constant is followed by the variable Z, an equal sign, and the 
user-selected variable X. 



GENERATE Z = X AND B 



The GENERATE constant is followed by the variable Z, an equal sign, the 
user-selected variable X, the AND command (from the list of user-selected items 
in the nested path), and a third variable, B. 



GENERATE Z = X + B 

The GENERATE constant is followed by the variable Z, an equal sign, the 
user-selected variable X, the plus sign (from the list of user-selected items in the 
nested path), and a third variable, B. 

Example 4 

<entity reference declaration> 
(4 

— ENTITY REFERENCE - 



entity ref ID>— { — <class ID>— ) 



Sample Input 

ENTITY REFERENCE ADVISORl (INSTRUCTOR) 

The required item ENTITY REFERENCE is followed by the variable ADVISORl 
and the variable INSTRUCTOR. The parentheses are required. 

ENTITY REFERENCE ADVISORl (INSTRUCTOR), ADVIS0R2 (ASST_INSTRUCTOR) 



This sample illustrates the use of a loop by showing the input that appears in the 
first sample followed by a comma, the variable ADVIS0R2, and the variable 
ASST_INSTRUCTOR. The parentheses are required. 
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Example 6 

— PS MODIFY 

4 



<request nuniber>- 



>- <request nuinber> <request number 

ALL 



r 



EXCEPTIONS 



— <file attribute phrase> 

J <pr1nt modifier phrase>-i 



Sample Input 

PS MODIFY 11159 

The constants PS and MODIFY are followed by the variable 11159, which is a 
request number. 

PS MODIFY 11159,11160,11163 

This sample illustrates the use of a loop by showing the input that appears in the 
first sample followed by a comma, the variable 11160, another comma, and the 
final variable 11163. 



PS MODIFY 11159-11161 DESTINATION = "LP?' 



The constants PS and MODIFY are followed by the user-selected variables 
11159-11161, which are request numbers, and the user-selected variable 
DESTINATION = "LP7 which is a file attribute phrase. 

PS MOD ALL, EXCEPTIONS 

The constants PS and MODIFY are followed by the user-selected constant ALL 
and the user-selected constant EXCEPTIONS. Note that in this sample input, the 
constant MODIFY has been abbreviated. v 
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A 

address couple 

A representation of the address of an item in a program. An address couple 
consists of two numbers: the first number is a lexical level, and the second 
number is a displacement (offset) within that lexical level. . 

ALGOL 

Algorithmic language. A structured, high-level programming language that 
provides the basis for the stack architecture of the Unisys A Series systems. 
ALGOL was the first block-structured language developed in the 1960s and 
served as a basis for such languages as Pascal and Ada. It is still used extensively 
on A Series systems, primarily for systems programming. 

ASCII 

American Standard Code for Information Interchange. A standard 7-bit or 8-bit 
information code used to represent alphanumeric characters, control characters, 
and graphic characters on a computer system. 



B 

BDMSALGOL 

A Unisys language based on Extended ALGOL that contains extensions for 
accessing Data Management System II (DMSII) databases. 

c 

C programming language 

A language developed by Bell Laboratories for the UNIX® oi>erating system. The 
C language is a block-structured language that features a rich set of operators, 
few restrictions on data type conversions, and economy of expression. 

CANDE 

See Command and Edit. 

COBOL 

Common Business-Oriented Language. A widely used, procedure-oriented 
language intended for use in solving problems in business data processing. The 



UNIX is a registered trademark of AT&T Information Systems. 
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main characteristics of COBOL are the easy readability of programs and a 
considerable degree of machine independence. COBOL is the most widely used 
procedure-oriented language. 

code file 

See object code file, source file. 

Command and Edit (CANDE) 

A time-sharing message control system (MCS) that enables a user to create and 
edit files, and to develop, test, and execute programs, interactively. 

copy descriptor 

A duplicate of a mom descriptor except the copy bit is set to 1. A copy descriptor 
is derived from a mom descriptor, and multiple copy descriptors can reference 
the same data segment. 



Data Communications ALGOL (DCALGOL) 

A Unisys language based on ALGOL that contains extensions for writing message 
control system (MCS) programs and other specialized system programs. 

Data Management ALGOL (DMALGOL) 

A Unisys language based on ALGOL that contains extensions for writing Data 
Management System II (DMSII) software and other specialized system programs. 

Data Management System H (DMSII) 

A specialized system software package used to describe a database and maintain 
the relationships among the data elements in the database. 

DCALGOL 

See Data Communications ALGOL. 

directory 

(1) A table of contents listing the files contained on a device. The device is 
usually a disk or a tape. 

(2) A list of file names organized into a hierarchy according to similarities in 
their names. File names are grouped in a directory if their first name constants 
(and associated usercodes) are identical. These groups are divided into 
subdirectories consisting of those file names whose first two name constants are 
identical, and so on. 

(3) In Data Management System II (DMSII), a file with the layout for each field 
of the record that it describes. A directory describes the layout of records within 
a file. 

(4) The partial name of a disk file up to one of the following terminators: a slash 
followed by an equal sign (/=) or a right parenthesis followed by an equal sign 

()=)• 

DMALGOL 

See Data Management ALGOL. 
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DMSn 

See Data Management System II. 

E 

EBCDIC 

Extended Binary Coded Decimal Interchange Code. An 8-bit code representing 256 
graphic and control characters that are the native character set of most 
mainframe systems. 

entity 

(1) An item about which information is stored. An entity can be tangible or 
intangible and is further defined by attributes, which are the characteristics of 
the entity. 

(2) In the Communications Management System (COMS), a category of items 
within the configuration file. 

(3) Any object defined in the Advanced Data Dictionary System (ADDS). To 
ADDS, an entity can be a Screen Design Facility (SDF) field, form, or formlibrary; 
an attribute or class in a Semantic Information Manager (SIM) database; a data 
set, group, or item in a Data Management System II (DMSII) database; or the 
entire SIM or DMSII database. Note that the definitions that are stored in 
ADDS— objects and their relationships — are themselves known as entities. 

(4) In the InfoExec environment, the basic unit of a Semantic Information 
Manager (SIM) database. A SIM entity can be any member of a SIM class, such as 
an employee, a department, or a project. 

entity reference variable 

In Semantic Information Manager (SIM) programs, a variable that refers 
explicitly to an entity. 

entry point 

A procedure or function that is a library object. 

external reference 

A reference to an external subprogram that is not bound into the host. 

F 

FORTRAN 

Formula Translation. A high-level, structured programming language intended 
primarily for scientific use. 

FORTRAN?? 

A version of the FORTRAN language that is compatible with the ANSI X3.9-1978 
standard. A version of the FORTRAN language that is compatible with the 
ANSI X3.9-1978 standard. 
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G 

global item 

In the Binder, an item that, in a host, is declared at the outermost lexical level or, 
in a subprogram, is declared at a lexical level less than that of the subprogram. 

H 

host nie 

The object code file to which separate subprograms are bound. A host file can be 
the resultant object code file of a previous bind and always contains the first 
executable object code segment of the resultant bound program. 

host program 

A program to which separately compiled procedures can be bound by using the 
Binder program or by using the SEPCOMP facility. 

I 

InfoExec 

Information Executive. The name of a family of Unisys products that define, 
maintain, retrieve, and update databases. 

Information Executive (InfoExec) 

See InfoExec. 

intrinsic 

A system-supplied program routine for common mathematical and other 
operations that is loaded onto the system separately. An intrinsic can be invoked 
by the operating system or user programs. 

L 

lex level 

See lexical level. 

lexical level Q^tl level) 

(1) A number that indicates the relative level of an addressing space within the 
stack of an executing program. Lexical levels range from 0 through either 15 or 
31, depending on the computer family. A lower lexical level indicates a more 
global addressing space. 

(2) A measure of the number of other blocks a block is nested within. The outer 
block of a program has a lex level of 2 or 3, depending on whether the program 
has a procedure heading. Each block has a lex level one higher than the block it 
is nested within. 
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library 

(1) A collection of one or more named routines or library objects that are stored 
in a file and can be accessed by other programs. 

(2) A program that exports objects for use by user programs. 

library object 

An object that is shared by a library and one or more user programs. 

M 

master control program (MCP) 

The central program of the A Series operating system. The term applies to any 
master control program that Unisys may release for A Series systems. 

MCP 

See master control program. 

N 

NEWP 

A structured, high-level progranuning language used in developing some Unisys 
system software. Based on the ALGOL language, NEWP contains facilities 
necessary for the operating system to interact with A Series hardware. 



object 

(1) Any item declared in a program. Arrays, files, procedures, tasks, and 
variables are all examples of objects. 

(2) The basic unit of data in the semantic data model (SDM), object-oriented 
databases (OODBs), and systems based on these technologies, such as the 
Semantic Information Manager (SIM). An object possesses both structure and 
behavior. In SIM, an object is also called an entity. See also entity. 

object code fUe 

A file produced by a compiler when a program is compiled successfully. The file 
contains instructions in machine-executable object code. 



ODT 



See operator display terminal. 



operator display terminal (ODT) 

(1) A terminal or other device that is connected to the system in such a way that 
it can communicate directly with the operating system. The ODT allows 
operations personnel to accomplish system operations functions through either of 
two operating modes: system command mode or data comm mode. 

(2) The name given to the system control terminal (SCT) when it is used as an 
ODT. 
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P 

Pascal 

A high-level programming language developed by Niklaus Wirth, based on the 
block structuring nature of ALGOL 60 and the data structuring innovations of 
C.A.R. Hoare. Pascal is a general-purpose language. 

PL/I 

Programming Language I. A high-level, structured programming language 
designed primarily for scientific and commercial use. 

primary input file 

In the Binder, the input Hie that contains the Binder control records and the 
Binder statements. 

Q 

query variable 

In Semantic Information Manager (SIM) application programs, a variable that 
represents the query statement. 

S 

Semantic Information Bfanager (SDH) 

The basis of the InfoExec environment. SIM is a database management system 
used to describe and maintain associations among data by means of 
subclass-superclass relationships and linking attributes. 

SOI 

See Semantic Information Manager, 
source file 

(1) A file in which a source program is stored. 

(2) A file containing instructions written in a programming language. 

(3) See SOURCE file. 

SOURCE file 

A secondary input file from which certain compilers read previously stored 
source images. 

subprogram file 

In the Binder, an object code Hie that contains one or more separate subprograms 
to be bound to a host file. 

w 

WFL 

5e6 Work Flow Language. 
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Work Flow Language (WFL) 

A Unisys language used for constructing jobs that compile or run programs on 
A Series systems. WFL includes variables, expressions, and flow-of -control 
statements that offer the programmer a wide range of capabilities with regard to 
task control. 
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libraries, 5-3 
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rectifying name of COMS library 
during, 5-4 
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binding with FORTRAN, 5-5 
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block, 5-9 
common blocks, accessing as an 

ALGOL array, 5-8 
common blocks, equating, 5-?, 5-8 
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example, 5-10 
file declarations, 5-7 
global items, sharing, 5-7 
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binding with FORTRAN (cont.) 
parameters, 5-6 
printing problems, avoiding, 5-7 
binding with FORTRAN??, 5-1 1 
arrays, accessing from a common 

block, 5-15 
arrays, declaring, 5-17 
common blocks, accessing as an 

ALGOL array, 5-14 
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5-16 
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parameters, 5-25 
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5-1 

files 
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corresponding FORTRAN 
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example, 4-5, 4-6, 4-7, 5-20 
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intralanguage binding, 4-1 
example, 4-5, 4-6, 4-7 
LABEL item restriction when 

binding, 4-2 
lexical level in intralanguage 

binding, 4-1 
library binding in, 4-5 

example, 4-6, 4-7 
LOADINFO record, 4-3 
NOBINDINFO option, 8-1 
procedures 

corresponding COBOL 

identifiers, 5-2 
corresponding FORTRAN 

identifiers, 5-5 
corresponding FORTRAN77 

identifiers, 5-12 
corresponding Pascal 
identifiers, 5-22 
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record binding in, 4-5 
SEPCOMP option, 4-4 
subprograms 

declaring global items in, 4-2, 4-3 
description, 4-1 
example, 4-6, 4-7, 4-8, 5-10, 
5-18, 5-20, 5-26, 5-43 
switch items, declaring, 4-2 
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corresponding FORTRAN77 
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corresponding Pascal 
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allowable binding combinations, 1-2 
arithmetic common blocks 

accessing a single-precision array 
through, 5-15 

arrays 
ALGOL 

accessing from a FORTRAN common 
block, 5-9 
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ALGOL (cont.) 

accessing from a FORTRAN77 

common block, 5-15 
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identifiers, 5-2 
corresponding FORTRAN 

identifiers, 5-5 
corresponding FORTRAN77 

identifiers, 5-12 
corresponding Pascal 
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declaring in ALGOL, 4-2 
double-precision 

accessing FORTRAN common blocks 

as, 5-9 
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blocks as, 5-14 
accessing from a common 
block, 5-9 
EBCDIC 

accessing FORTRAN77 common 

blocks as, 5-15 
accessing through a FORTRAN77 
common block, 5-16 
equivalence 

length in bound code file, 5-16 
passing between ALGOL and 

COBOL, 5-3 
passing between ALGOL and 

FORTRAN77, 5-17 
single-precision 

accessing FORTRAN common blocks 

as, 5-9 
accessing FORTRAN77 common 

blocks as, 5-14 
accessing from a common 

block, 5-9 
accessing through a FORTRAN77 
common block, 5-15 
size in bound code file, 4-2 

B 

BDMSALGOL iSee also AL(K)L), 4-1 
BIND statement 

affect on named subprograms, 1-7 
binding external subprograms 

with, 3-3 
conflict with DONTBIND 
statement, 3-6 
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BIND statement (cont.) 

discussion, 3-2 

examples, 3-4 

for C programs, 3-3 

purpose, 3-2 

syntax, 3-2 
Binder 

action on named subprograms, 1-7 
code file restrictions, I-l 
control record options, B-4 
control records 

explanation, B-1 

explanation of syntax, B-2, B-3 

ignoring columns in, B-1 

including options in, B-1 

syntax, B-1, B-2, B-3 
description, 1-1 
error messages, A-1 
executing 

withCANDE, 1-6 

with WFL, 1-7 
execution process, description, 1-7 
input files, 1-2 

CARD, 1-2 

for intrinsics, 6-1, 6-3 

host program, 1-3 

primary, 1-2 

subprogram, 1-3 
intrinsics file, 6-1, 6-3 
language constructs 

file specifier, 2-1 

identifier, 2-3 

intrinsic specification, 2-3 

subprogram identifier, 2-5 
output files 

bound code file, 1-4 

description, 1-4 

error, 1-5 

printer, 1-4 
records 

ignoring, 3-1 

use of percent sign in, 3-1 

use of semicolon (;) in, 3-1 
reserved words, 1-7 
statements 

BIND, 3-2 

DONTBIND, 3-5 

EXTERNAL, 3-7 

HOST, 3-7 

INITIALIZE, 3-8 

PURGE, 3-9 

STOP, 3-9 
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statements (cont.) 
table, 3-1 
USE, 3-10 

use of percent sign in, 3-1 
use of semicolon in, 3-1 
BINDERINPUT file 

created by the Pascal compiler, 5-24, 
5-36 

created by the Pascal compiler 
(example), 5-26, 5-38 
BINDINFO option 
in COBOL, 8-1 
inFORTRAN77, 8-1 
binding 

ALGOL and COBOL, 5-2 

corresponding identifiers, 5-2 

declaring global items, 5-3 

parameters, 5-3 
ALGOL and COBOL74 programs that 

use COMS, 5-4 
ALGOL and FORTRAN, 5-5 

arrays, accessing from a common 
block, 5-9 

common blocks, accessing as ALGOL 
arrays, 5-8 

common blocks, declaring, 5-7 

corresponding identifiers, 5-5 

example, 5-10 

file declarations in, 5-7 

parameters, 5-6 

printing problems, avoiding, 5-7 

sharing global items, 5-7 
ALGOL and FORTRAN77, 5-1 1 

arrays, accessing from a common 
block, 5-15 

arrays, declaring, 5-17 

common blocks, accessing as ALGOL 
arrays, 5-14 

common blocks, declaring, 5-14 

corresponding identifiers, 5-12 

example, 5-18, 5-19, 5-20 

file declarations in, 5-13 

parameters, 5-17 

printing problems, avoiding, 5-14 

sharing global items, 5-12 

subprogram restrictions, 5-13 
ALGOL and NEWP, 5-21 

subprogram requirements, 5-21 
ALGOL and Pascal, 5-22 

corresponding identifiers, 5-22 

example, 5-25, 5-27 
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ALGOL and Pascal (cont.) 

parameters, 5-25 

sharing global items, 5-24 
ALGOL, COBOL, and FORTRAN?? 

example, 5-42 
ALGOL with ALGOL, 4-1 
allowable language combinations, 1-2 
C with C, 4-9 
COBOL and FORTRAN, 5-2? 
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parameters, 5-29 
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COBOL and FORTRAN??, 5-29 

corresponding identifiers, 5-29 

example, 5-31 

parameters, 5-31 

sharing global items, 5-30 
COBOL and Pascal, 5-33 

corresponding identifiers, 5-33 

example, 5-37, 5-38 

parameters, 5-36 

sharing global items, 5-35 
COBOL with COBOL, 4-10 
errors during, 1-8 
FORTRAN and FORTRAN??, 5-39 

common blocks, 5-40 

corresponding identifiers, 5-39 

example, 5-41 

parameters, 5-40 
FORTRAN with FORTRAN, 4-15 
FORTRAN?? with FORTRAN??, 4-1? 
interlanguage 

definition, 5-1 

valid language combinations, 5-1 
intralanguage 

definition, 4-1 

languages excluded from, 4-1 
intrinsics, 6-1 

syntax, 6-2 

without host program, 3-3 
libraries 

ALGOL and COBOL, 5-3 

FORTRAN and FORTRAN??, 5-41 

in ALGOL, 4-5 

in ALGOL (example), 4-6, 4-? 

in COBOL, 4-13 

in FORTRAN, 4-16 

in FORTRAN??, 4-18 
PL/I with PL/I, 4-21 
records 

ALGOL and COBOL, 5-4 
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records (cont.) 

in ALGOL, 4-5 
reducing I/O time used in, 1-9 
replacement {See also replacement 

binding), 1-3 
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that access DMSII databases, ?-l 
that access SIM databases, ?-l 
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for ALGOL, 8-1 
for COBOL, 8-1 
for FORTRAN, 8-1 
for FORTRAN??, 8-1 
for Pascal, 8-1 
printing, 8-2 
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5-14 
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bound code file 

description, 1-4 

length of common block in, 4-16, 
4-18 

size of array in, 4-2 
brackets method for declaring global 
items in ALGK)L 
subprograms, 4-2 

c 

c 

BIND statement for, 3-3 
binding combinations, 1-2 
binding with C, 4-9 
host program 

description, 4-9 

example, 4-9 
intralanguage binding, 4-9 

example, 4-9 
subprogram 

description, 4-9 

example, 4-10 
CALL verb, in COBOL, 4-1 1 
COBOL 

BINDINFO option, 8-1 

binding an external procedure, 4-11 

binding combinations, 1-2 
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COBOL (cont.) 

binding information, generating, 8-1 
binding with ALGOL, 5-2 

corresponding identifiers, 5-2 

global items, declaring, 5-3 

libraries, 6-3 

parameters, 5-3 

records, 5-4 

rectifying name of COMS library 
during, 5-4 
binding with ALGOL and FORTRAN?? 

example, 5-42 
binding with COBOL, 4-10 
binding with FORTRAN, 5-2? 

corresponding identifiers, 5-2? 

global items, sharing, 5-28 

parameters, 5-29 
binding with FORTRAN??, 5-29 

corresponding identifiers, 5-29 

example, 5-31 

global items, sharing, 5-30 

parameters, 5-31 
binding with Pascal, 5-33, 5-35 

corresponding identifiers, 5-33 

example, 5-3?, 5-38 

global items, sharing, 5-35 

parameters, 5-36 
CALL verb, 4-11 
ENTER verb, 4-11 
GLOBAL clause, 4-11 
host program 

description, 4-11 

example, 4-13 
intralanguage binding, 4-10 

CODE FILE TITLE option in, 4-11 

example, 4-13 
library binding in, 4-13 
LOCAL option, 4-12 
OWN option, 4-12 
subprogram 

example, 5-32, 5-43, 5-44 
subprograms 

declaring global items in, 4-11 

declaring global items in 
(example), 4-11 

description, 4-11 

example, 4-14 

lexicail level of , 4-11 
COBOL68 (See COBOL) 
COBOL74 (See COBOL) 
COBOL85 (See COBOL) 



code file 
bound 

description, 1-4 
length of common block in, 4-16 
size of array in, 4-2 
unresolved external references 
in, 1-5 
indicating title in COBOL 
binding, 4-1 1 
CODE option in Binder control 

record, B-4 
CODEN option in Binder control 

record, B-4 
common blocks 

accessing ALGOL arrays from, 5-9, 
5-15 

accessing as ALGOL arrays, 5-8, 

5-14 
arithmetic 

accessing a single-precision array 

through an, 5-15 
binding in FORTRAN??, 4-18 
blank, 5-8,5-14 ^ 
declaring, 5-?, 5-14 
description, 5-7 

equating with ALGOL arrays, 5-?, 

5-14 
FORTRAN 

corresponding COBOL 
identifiers, 5-2? 
FORTRAN?? 

corresponding COBOL 
identifiers, 5-29 
length in bound code file, 4-16, 4-18 
passing between FORTRAN and 

FORTRAN??, 5-40 
simulating in ALGOL, 5-8, 5-16 
using data-initialized values 
with, 5-15 
compiler control options 
ALGOL 

DUMPINFO, 4-3 
INSTALLATION, 6-1 
LOADINFO, 4-3 
NOBINDINFO, 8-1 
SEPCOMP, 4-4 
COBOL 

BINDINFO, 8-1 
GLOBAL, 4-12, 5-3 
LOCAL, 4-12 
OWN, 4-12 
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compiler control options (cont.) 
FORTRAN 

INSTALLATION, 6-1 
NOBINDINFO, 8-1 
FORTRAN?? 

BINDINFO, 8-1 
COMS 

binding ALGOL and C0B0L?4 
programs that use, 5-4 
library 

rectifying name between ALGOL and 
COBOL, 5-4 
conflict between BIND and DONTBIND 

statements, 3-6 
constructs 

Binder language 
file specifier, 2-1 
identifier, 2-3 
intrinsic specification, 2-3 
subprogram identifier, 2-5 
SIM 

DMRECORD variable, ?-2 
entity reference variable, 7-2 
query variable, 7-2 
control records. Binder 

explanation, B-1 

explanation of syntax, B-2, B-3 

ignoring columns in, B-1 

including options in, B-1 

options for, B-4 

syntax, B-1, B-2, B-3 

D 

data types, SIM, 7-2 
database binding 

referencing from a subprogram, 7-2 
databases 

binding a DMSII, 7-1 

binding a SIM, 7-1 
data-initialized values 

using with FORTRAN common 
blocks, 5-15 
DCALGOL (See also ALGOL), 4-1 
DEBUG option, PRINTBINDINFO 

utility, 8-6 
declaring 

blank common blocks, 5-8, 5-14 



declaring (cont.) 

files in FORTRAN??, 4-18 
FORTRAN common blocks, 5-8 
FORTRAN?? common blocks, 5-14 
functions 

when binding C with C, 4-9 
global items 

in ALGOL host programs, 4-3, 4-4 
in ALGOL subprograms, 4-2, 4-3 
in COBOL subprograms, 4-11 
when binding ALGOL and 

COBOL, 5-3 
when binding ALGOL and 

FORTRAN, 5-7 
when binding ALGOL and 

Pascal, 5-24 
when binding COBOL and 
Pascal, 5-35 
parameters 

in COBOL intralanguage 
binding, 4-11 
SIM databases, 7-2 
STATIC EXTERNAL variables in 

PL/I, 4-22 
variables 

when binding C with C, 4-9 
<digit>, 2-2, 3-8 
directory name in a file specifier, 2-2 
<directory specif ier>, 2-3 
DMALGOL iSee also ALGOL), 4-1 
DMRECORD variable in SIM, 7-2 
DMSII databases 

binding programs that access, 7-1 
dollar sign ($) 

use in Binder control record, B-1 
DONTBIND statement 

conflict with BIND statement, 3-6 
discussion, 3-5 
examples, 3-6 
purpose, 3-5 
syntax, 3-5 
double-precision arrays 

accessing FORTRAN common blocks 
as, 5-9 

accessing FORTRAN?? common blocks 

as, 5-14 
accessing from a common block, 5-9 
DUMPINFO 

record, in ALGOL, 4-3 
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E 

EBCDIC array 

accessing a FORTRAN?? common block 
as an, 5-15 

accessing through a FORTRAN?? 
common block, 5-16 
EBCDIC character 

use in file specifier, 2-2 
efficiency 

in binding, 1-9 

in object-code, 1-9 
ENTER verb, in COBOL, 4-11 
entity reference variable in SIM, ?-2 
equal sign (=) 

use in BIND statement, 3-3 

use in file specifier, 2-2 
equivalence array 

length in bound code file, 5-16 
ERRLIST option in Binder control 

record, B-4 
error file 

description, 1-5 
error messages, A-1 
ERRORLIST option in Binder control 
record, B-4 

errors 

during binding, 1-8 
examples 

ALGOL host program, 4-5, 4-6, 4-?, 
5-20 

ALGOL intralanguage binding, 4-5, 

4- 6, 4-? 

ALGOL subprogram, 4-6, 4-7, 4-8, 

5- 10, 5-18, 5-20, 5-26, 5-43 
BIND statement, 3-4 
BINDERINPUT file created by the 

Pascal compiler (example), 5-26 
binding ALGOL and FORTRAN, 5-10 
binding ALGOL and 

FORTRAN??, 5-18, 5-19, 5-20 
binding ALGOL and Pascal, 5-25, 

5-2? 

binding ALGOL, COBOL, and 

FORTRAN??, 5-42 
binding COBOL and 

FORTRAN??, 5-31 
binding COBOL and Pascal, 5-3?, 

5-38 

binding FORTRAN and 
FORTRAN??, 5-41 



examples (cont.) 

C host program, 4-9 

C intralanguage binding, 4-9 

C subprogram, 4-10 

COBOL host program, 4-13 

COBOL intralanguage binding, 4-13 

COBOL subprogram, 4-14, 5-32, 

5-43, 5-44 
control records, using SET and RESET 

options, B-3 
declaring STATIC EXTERNAL 

variables in PL/I, 4-22 
<directory specif ier>, 2-3 
DONTBIND statement, 3-6 
<file specif ier>, 2-3 
FORTRAN host program, 4-16, 5-10 
FORTRAN intralanguage 

binding, 4-16 
FORTRAN subprogram, 4-1 ?, 5-1 1 , 

5-42 

FORTRAN?? host program, 4-19, 

5-18, 5-19, 5-31, 5-41, 5-42 
FORTRAN?? intralanguage 

binding, 4-18 
FORTRAN?? subprogram, 4-19, 5-21 
global items in COBOL 

subprograms, 4-11 
GLOBAL option in COBOL 

binding, 4-12 
HOST statement, 3-8 
INITIAUZE statement, 3-9 
Pascal host program, 5-25, 5-3? 
PL/I host program, 4-23 
PL/I intralanguage binding, 4-23 
PL/I subprogram, 4-23 
primary input file, 4-6, 4-?, 4-8, 

4- 10, 4-15, 4-1?, 4-19, 4-23, 

5- 11, 5-19, 5-20, 5-21, 5-32, 
5-42, 5-45 

PURGE statement, 3-9 
referencing a SIM database by a 

subprogram, ?-2 
restricting PRINTBINDINFO utility 

analysis, 8-4 
running the PRINTBINDINFO 

utility, 8-3 
SIM database 

accessed by Pascal host 

program, 7-8 
SIM entity reference variable, 

referenced by subprogram, 7-4 
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examples (cont.) 

SIM query variable referenced by 
subprogram, 7-5 

STOP statement, 3-10 

USE statement, 3-11 
executing Binder 

with CANDE, 1-6 

with WFL, 1-7 
execution process of Binder, 

description, 1-7 
EXTERNAL 

directive in Pascal, 5-24, 5-36 
external procedure 

binding in COBOL, 4-11 
external references, unresolved 

avoiding, 1-5 

causes of, 1-5 

definition, 1-5 
EXTERNAL statement (See also 
DONTBIND statement) 

effect on named subprograms, 1-7 

purpose, 3-7 

syntax, 3-7 
external subprograms 

BIND statement for, 3-3 

description, 1-3 

F 

<family name>, 2-2 

family name, use in file specifier, 2-2 

file specifier 

directory name in, 2-2 

equal sign in, 2-2 

examples, 2-3 
<file specif ier> 

examples of, 2-3 
file specifier 

explanation, 2-2 

syntax, 2-1 
<file specifier> 

syntax, 2-1 

use in BIND statement, 3-2 
use in HOST statement, 3-7 
use in PURGE statement, 3-9 
files 
ALGOL 

corresponding COBOL 

identifiers, 5-2 
corresponding FORTRAN 
identifiers, 5-5 



files (cont.) 
ALGOL (cont.) 

corresponding FORTRAN77 

identifiers, 5-12 
corresponding Pascal 
identifiers, 5-22 
Binder input, 1-2 
CARD, 1-2 
for intrinsics, 6-1,6-3 
host program, 1-3 
primary input, 1-2 
subprogram, 1-3 
Binder output 

bound code file, 1-4 
description, 1-4 
error, 1-5 
printer, 1-4 
BINDERINPUT 

created by the Pascal 

compiler, 5-24, 5-36 
created by the Pascal compiler 
(example), 5-26, 5-38 
bound code 

description, 1-4 
length of common block in, 4-16, 
4-18 

size of array in, 4-2 
unresolved external references 
in, 1-5 
CARD, description, 1-2 
declarations in ALCrOL and FORTRAN 

binding, 5-7 
declarations in ALGOL and 

FORTRAN77 binding, 5-13 
declaring in FORTRAN77, 4-18 
host program 
definition, 1-1 
description, 1-3 
passing between ALGOL and 

COBOL, 5-3 
primary input 
description, 1-2 
example, 4-6, 4-7, 4-8, 4-10, 

4- 15, 4-17, 4-19, 4-23, 5-11, 

5- 19, 5-20, 5-21, 5-32, 5-42, 
5-45 

printer output, description, 1-4 
SELECTIDS in PRINTBINDINFO 

utility, 8-4 
subprogram 

affect of BIND statement on during 

binding, 1-7 
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files (cont.) 

subprogram (cont.) 

binding of, 1-8 

definition, 1-1 

description, 1-3 

effect of EXTERNAL statement on 
during binding, 1-7 

nesting structure of, 2-6 

processing by Binder, 1-7 

titling of, 1-4 
FORTRAN 

binding combinations, 1-2 

binding information, generating, 8-1 

binding with ALGOL, 5-5 

arrays, accessing from a common 
block, 5-9 

common blocks, accessing as an 
ALGOL array, 5-8 

common blocks, declaring, 5-7 

corresponding identifiers, 5-5 

example, 5-10 

file declarations, 5-7 

global items, sharing, 5-7 

parameters, 5-6 

printing problems, avoiding, 5-7 
binding with COBOL, 5-27 

corresponding identifiers, 5-27 

global items, sharing, 5-28 

parameters, 5-29 
binding with FORTRAN, 4-15 
binding with FORTRAN77, 5-39 

common blocks, 5-40 

corresponding identifiers, 5-39 

example, 5-41 

libraries, 5-41 

parameters, 5-40 

replacing a main program with a 
subroutine, 5-40 
common blocks 

accessing AUQOL arrays from, 5-9 

accessing as ALGOL arrays, 5-8 

corresponding COBOL 
identifiers, 6->27 

declaring, 5-7 

description, 5-7 

equating with ALGOL arrays, 5-7 
length after binding, 4-16 
simulating in ALGrOL, 5-8 
using data-initialized values 
with, 5-15 
host program 

description, 4-15 



FORTRAN (cont.) 
host program (cont.) 

example, 4-16, 5-10 
INSTALLATION option, 6-1 
intralanguage binding, 4-15 

example, 4-16 
library binding in, 4-16 
NOBINDINFO option, 8-1 
subprogram 

description, 4-15 

example, 4-17, 5-11, 5-42 
variable 

corresponding COBOL 
identifiers, 5-27 
FORTRAN77 

BINDINFO option, 8-1 
binding combinations, 1-2 
binding information, generating, 8-1 
binding with ALGOL, 5-11 

arrays, accessing from a common 
block, 5-15 

arrays, declaring, 5-17 

common blocks, accessing as an 
ALGOL array, 5-14 

common blocks, declaring, 5-14 

corresponding identifiers, 5-12 

example, 5-18, 5-19, 5-20 

file declarations, 5-13 

global items, sharing, 5-12 

parameters, 5-17 

printing problems, avoiding, 5-14 

subprogram restrictions, 5-13 
binding with ALGOL and COBOL 

example, 5-42 
binduig with COBOL, 5-29 

corresponding identifiers, 5-29 

example, 5-31 

global items, sharing, 5-30 

parameters, 5-31 
binding with FORTRAN, 5-39 

common blocks, 5-40 

corresponding identifiers, 5-39 

example, 5-41 

libraries, 5-41 

parameters, 5-40 
binding with FORTRAN77, 4-17 
common blocks 

accessing ALGOL arrays 
from, 5-15 

accessing as ALGOL arrays, 5-14 

corresponding COBOL 
identifiers, 5-29 
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FORTRAN?? (cont.) 
common blocks (cont.) 
declaring, 5-14 

equating with ALGOL arrays, 5-14 
simulating in ALGOL, 5-16 
file declarations, 4-18 
host program 

description, 4-17 
example, 4-19, 5-18, 5-19, 5-31, 
5-41, 5-42 
intralanguage binding, 4-17 

example, 4-18 
length of common block after 

binding, 4-18 
library binding in, 4-18 
subprogram 

description, 4-17 
example, 4-19, 5-21 
variable 

corresponding COBOL 
identifiers, 5-29 
<from part> 

use in BIND statement, 3-2 
functions, declaring 

when binding C with C, 4-9 

G 

GLOBAL 

clause in COBOL, 4-11 

option in COBOL, 5-3 
global items 

ALGOL-Pascal binding, 6-27 

declaring in ALGOL host 
programs, 4-3, 4-4 

declaring in ALGOL subprograms, 4-2 
with brackets method, 4-2 
with INFO file method, 4-3 

declaring in COBOL, 4-11 

sharing between 

ALGOL and COBOL, 5-3 
ALGOL and FORTRAN, 5-7 
ALGOL and FORTRAN??, 5-12 
ALGOL and Pascal, 5-24 
COBOL and FORTRAN, 5-28 
COBOL and FORTRAN??, 5-30 
COBOL and Pascal, 5-35 



H 

HOST option in Binder control 

record, B-4 
host program 
ALGOL 

declaring global items in, 4-3, 4-4 

description, 4-1 

example, 4-5, 4-6, 4-7, 5-20 

C 

description, 4-9 

example, 4-9 
COBOL 

description, 4-11 

example, 4-13 
definition, 1-1 
description, 1-3 
examples of, 1-3 
FORTRAN 

description, 4-15 

example, 4-16, 5-10 
FORTRAN?? 

description, 4-17 

example, 4-19, 5-18, 5-19, 5-31, 
5-41, 5-42 
Pascal 

example, 5-25, 5-37 
PL/I 

description, 4-21 
example, 4-23 
HOST statement 

effect of multiple, 3-8 

effect on file equation, 3-8 

examples, 3-8 

purpose, 3-7 

syntax, 3-7 
<hyphen>, 2-2 
hyphen character 

use in file specifier, 2-2 



1 

<identifier> 
examples, 2-7 
syntax, 2-3 

use in INITIALIZE statement, 3-8 
use in USE statement, 3-10 
identifiers, corresponding 
ALGOL and COBOL, 5-2 
ALGOL and FORTRAN, 5-5 
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identifiers, corresponding (cont.) 
ALGOL and FORTRAN??, 5-12 
ALGOL and Pascal, 5-22 
COBOL and FORTRAN, 5-27 
COBOL and FORTRAN??, 5-29 
COBOL and Pascal, 6-33 
FORTRAN and FORTRAN??, 5-39 
IGNORELOCALDIR option, 

PRINTBINDINFO utility, 8-6 
INFO file method for declaring global 
items in ALGOL 
subprograms, 4-3 
initial values, using with FORTRAN 

common blocks, 5-15 
INITIALIZE statement 
examples, 3-9 
purpose, 3-8 
syntax, 3-8 
input files. Binder, 1-2 
CARD, 1-2 
host program, 1-3 
primary, 1-2 
subprogram, 1-3 
<integer>, 3-8 
interlanguage binding 

ALGOL and COBOL, 5-2 

corresponding identifier types, 5-2 
declaring global items, 5-3 
libraries, 5-3 
parameters, 5-3 
records, 5-4 

rectifjring name of COMS library 

during, 5-4 
ALGOL and FORTRAN, 5-5 
arrays, accessing from a common 

block, 5-9 
common blocks, accessing as ALGOL 

arrays, 5-8 
common blocks, declaring, 5-? 
corresponding identifier types, 5-5 
example, 5-10 
nie declarations, 5-? 
parameters, 5-6 
printing problems, avoiding, 5-? 
sharing global items, 5-? 
ALGOL and FORTRAN??, 6-1 1 
arrays, accessing from a common 

block, 5-15 
arrays, declaring, 5-1? 
common blocks, accessing as ALGOL 

arrays, 5-14 
common blocks, declaring, 6-14 



interlanguage binding (cont.) 
ALGOL and FORTRAN?? (cont.) 

corresponding identifier 
types, 5-12 

example, 5-18, 5-19, 5-20 

file declarations, 5-13 

parameters, 5- 1 ? 

printing problems, avoiding, 5-14 

sharing global items, 5-12 

subprogram restrictions, 5-13 
ALGOL and NEWP, 5-21 

subprogram requirements, 5-21 
ALGOL and Pascal, 5-22 

corresponding identifier 
types, 5-22 

example, 5-25, 5-27 

parameters, 5-25 

sharing global items, 5-24 
AL(}OL, COBOL, and FORTRAN??, 

example, 5-42 
COBOL and FORTRAN, 5-2? 

corresponding identifier 
types, 5-2? 

parameters, 5-29 

sharing global items, 5-28 
COBOL and FORTRAN??, 5-29 

corresponding identifier 
types, 5-29 

example, 5-31 

parameters, 5-31 

sharing global items, 5-30 
COBOL and Pascal, 5-33, 6-36 

corresponding identifier 
types, 5-33 

example, 5-37, 5-38 

parameters, 5-36 

sharing global items, 6-35 
definition, 5-1 

FORTRAN and FORTRAN??, 5-39 

common blocks, 5-40 

corresponding identifier 
types, 5-39 

example, 6-41 

libraries, 5-41 

parameters, 6-40 
valid language combinations, 5-1 
intralanguage binding 
AL(K)L 

description, 4-1 

example of, 4-5, 4-6, 4-7 

lexical level in, 4-1 
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intralanguage binding (cont.) 

C 

description, 4-9 

example of, 4-9 
COBOL 

description, 4-10 

example of, 4-13 
definition, 4-1 
FORTRAN 

description, 4-15 

example of, 4-16 
FORTRAN?? 

description, 4-17 

example of, 4-18 
languages excluded from, 4-1 
PL/I 

description, 4-21 
example of, 4-23 
<intrinsic number pair>, 2-3, 6-2 
<intrinsic specif ication>, 2-3 
use in BIND statement, 3-2 
intrinsics 

Binder input file for, 6-1 

example, 6-3 
binding, 6-1 

without a host program, 3-3 
compiling, requirements for, 6-1 
description, 6-1 
number pair construct, 2^ 
specification construct 
examples, 2-4 
explanation, 2-4 
syntax, 2-3 
INTRINSICS option in Binder control 

record, B-4 
invoking Binder 
with CANDE, 1-6 
with WFL, 1-? 
I/O time 

reducing during binding, 1-9 

L 

LABEL item, restriction in ALGOL 

binding, 4-2 
language combinations valid for 

binding, 5-1 
language constructs, Binder 
file specifier, 2-1 
identifier, 2-3 
intrinsic specification, 2-3 



language constructs, Binder (cont.) 

subprogram identifier, 2-5 
<language list>, 2-3, 6-2 
<letter>, 2-2 
lexical level 

in ALGOL intralanguage binding, 4-1 
of COBOL subprograms, 4-11 
library 
binding 

ALGOL, 4-5,4-6,4-7 
ALGOL and COBOL, 5-3 
COBOL, 4-13 
FORTRAN, 4-16 
FORTRAN and FORTRAN??, 5-41 
FORTRAN??, 4-18 
mismatch errors, preventing, 5-4 
LINEINFO option in Binder control 

record, B-5 
LIST option in Binder control 

record, B-5 
LOADINFO 

record, in ALGOL, 4-3 
LOCAL option 
in COBOL, 4-12 



M 

main program, replacing with a 
subroutine, 5-40 

MAP option in Binder control 
record, B-5 

matching identifiers between 
ALGOL and COBOL, 5-2 
ALGOL and FORTRAN, 5-5 
ALGOL and FORTRAN??, 5-12 
ALGOL and Pascal, 5-22 
COBOL and FORTRAN, 5-2? 
COBOL and FORTRAN??, 5-29 
COBOL and Pascal, 5-33 
FORTRAN and FORTRAN??, 6-39 

messages, warning and error, A-1 



N 

nesting structure, program, 2-6 
NEWP 

binding combinations, 1-2 
binding with ALGOL, 5-21 

subprogram requirements, 5-21 
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NOBINDINFO option 

in ALGOL, 8-1 

in ALGOL and FORTRAN, 8-1 

in Binder control record, B-5 

in FORTRAN, 8-1 
<nonquote EBCDIC character>, 2-2 
<nonquote identifier>, 2-2 
nonquote identifier, use in file 

specifier, 2-2 
NOREFERENCES option, 

PRINTBINDINFO utility, 8-6 



0 

object-code efficiency, 1-9 
options 

Binder control record, B-4 
in ALGOL 

DUMPINFO, 4-3 

INSTALLATION, 6-1 

LOADINFO, 4-3 

NOBINDINFO, 8-1 

SEPCOMP, 4-4 
in COBOL 

BINDINFO, 8-1 

GLOBAL, 4-12 

LOCAL, 4-12 

OWN, 4-12 
in FORTRAN 

INSTALLATION, 6-1 

NOBINDINFO, 8-1 
in FORTRAN?? 

BINDINFO, 8-1 
in PRINTBINDINFO utility 

DEBUG, 8-6 

IGNORELOCALDIR, 8-6 

NOREFERENCES, 8-6 
output files, Binder 
bound code file, 1-4 
description, 1-4 
error, 1-5 
printer, 1-4 
OWN option 

in COBOL, 4-12 
OWN option, in COBOL, 4-12 



P 

parameters 
declaring 

in COBOL intralanguage 
binding, 4-1 1 
passing between 

ALGOL and COBOL, 5-3 
ALGOL and FORTRAN, 5-6 
ALGOL and FORTRAN??, 5-1? 
ALGOL and Pascal, 5-25 
COBOL and FORTRAN, 5-29 
COBOL and FORTRAN??, 5-31 
COBOL and Pascal, 5-36 
FORTRAN and FORTRAN??, 5-40 
Pascal 

binding combinations, 1-2 

binding information, generating, 8-1 

binding with ALGOL, 5-22 

corresponding identifiers, 5-22 
example, 5-25, 5-2? 
global items, 5-2? 
global items, sharing, 5-24 
parameters, 5-25 
binding with COBOL, 5-33, 5-35 
corresponding identifiers, 5-33 
example, 5-3?, 5-38 
global items, sharing, 5-35 
parameters, 5-36 
EXTERNAL directive in, 5-24, 5-36 
host program, example, 5-25, 5-3? 
passing a system file 

from Pascal host to COBOL 
subprogram, 5-38 
percent sign (%), use in Binder control 

record, B-1 
percent sign (%), use in Binder control 
records, 3-1 

PL/I 

binding combinations, 1-2 
binding with PL/I, 4-21 
host program 

description, 4-21 

example, 4-23 
intralanguage binding, 4-21 

example, 4-23 
STATIC EXTERNAL variables, 4-22 
subprogram 

description, 4-21 

example, 4-23 
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primary input file 
description, 1-2 

example, 4-6, 4-7, 4-8, 4-10, 4-15, 

4- 17, 4-19, 4-23, 5-11, 5-19, 

5- 20, 5-21, 5-32, 5-42, 5-45 
PRINTBINDINFO utility 

DEBUG output option, 8-6 
description, 8-1 
IGNORELOCALDIR output 

option, 8-6 
NOREFERENCES output option, 8-6 
printer format options, 8-6 
restricting the analysis, 8-4 
running (example), 8-3 
SELECTIDS file, 8-4 
starting, 8-2 

TASKVALUE attribute, 8-6 
printer 

format options, PRINTBINDINFO 

utility, 8-6 
listing, 1-4 

output file, description, 1-4 
printing 

avoiding problems in ALGOL and 

FORTRAN binding, 5-7 
avoiding problems in ALGOL and 
FORTRAN77 binding, 5-14 
binding information, 8-2 
procedures 
ALGOL 

corresponding COBOL 

identifiers, 5-2 
corresponding FORTRAN 

identifiers, 5-5 
corresponding FORTRAN77 

identifiers, 5-12 
corresponding Pascal 
identifiers, 5-22 
restriction when binding ALGOL and 
COBOL, 5-3 
program 

host {See also host program), 1-1 
nesting structure of, 2-6 
PURGE statement 
examples, 3-9 
purpose, 3-9 
syntax, 3-9 



Q 

query variable in SIM, 7-2 
question mark (?), use in BIND 
statement, 3-3 

R 

records 

Binder control 
explanation, B-1 
explanation of syntax, B-2, B-3 
ignoring, 3-1 
ignoring columns in, B-1 
including options in, B-1 
options for, B-4 
syntax, B-1, B-2, B-3 
use of percent sign in, 3-1 
binding ALGOL and COBOL, 5-4 
binding in ALGOL, 4-5 
DUMPINFO, in ALGOL, 4-3 
LOADINFO, in ALGOL, 4-3 
reducing I/O time during binding, 1-9 
referencing a SIM database from a 

subprogram, 7-2 
replacement binding, 1-3, 3-2 
reserved words, 1-7 
restricting PRINTBINDINFO utility 
analysis, 8-4 

S 

SEG option in Binder control 

record, B-5 
SELECTIDS file, using with 

PRINTBINDINFO utility, 8-4 
semicolon (;), use in Binder records, 3-1 
SEPCOMP option, in ALGOL, 4-4 
SIM 

constructs 

DMRECORD variable, 7-2 
entity reference variable, 7-2 
query variable, 7-2 
data types, 7-2 
da.tabases 

accessed by a Pascal host program 
(example), 7-8 
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SIM (cont.) 

databases (cont.) 

binding programs that access, 7-1 
declaring, 7-2 
referenced by subprogram 

(example), 7-2 
referenced in subprograms by entity 

reference variable, 7-4 
referenced in subprograms by query 
variable (example), 7-5 
single-precision arrays 

accessing FORTRAN common blocks 
as, 5-9 

accessing FORTRAN77 common blocks 

as, 5-14 
accessing from a common block, 5-9 
accessing through FORTRAN77 
common blocks, 5-15 
slash (/), use in common block 

declaration, 5-7 
STACK option in Binder control 

record, B-5 
starting Binder 

with CANDE, 1-6 
with WFL, 1-7 
statements. Binder 
BIND 

binding external subprograms 

with, 3-3 
conflict with DONTBIND 

statement, 3-6 
discussion, 3-2, 3-5 
examples, 3-4, 3-6 
for C programs, 3-3 
purpose, 3-2 
syntax, 3-2 
DONTBIND 

conflict with BIND statement, 3-6 
purpose, 3-5 
syntax, 3-5 
EXTERNAL 
purpose, 3-7 
syntax, 3-7 
EXTERNAL {See also DONTBIND 

statement), 3-7 
HOST 

effect of multiple, 3-8 
effect on file equation, 3-8 
examples, 3-8 
purpose, 3-7 
syntax, 3-7 



statements, Binder (cont.) 
INITIALIZE 

examples, 3-9 

purpose, 3-8 

syntax, 3-8 
PURGE 

examples, 3-9 

purpose, 3-9 

syntax, 3-9 
STOP 

example, 3-10 

purpose, 3-9 

syntax, 3-9 
table, 3-1 
USE 

discussion, 3-10 
examples, 3-11 
purpose, 3-10 
syntax, 3-10 
use of semicolon in, 3-1 
STATIC EXTERNAL variables in 

PL/I, 4-22 
STOP statement 
example, 3-10 
purpose, 3-9 
syntax, 3-9 
STRICT option in Binder control 

record, B-5 
subprogram 

referencing a SIM database from, 7-2 
<subprogram identifier>, 2-5 
syntax, 2-5 

use in BIND statement, 3-2 
use in DONTBIND statement, 3-5 
use in EXTERNAL statement, 3-7 
use in USE statement, 3-10 
subprograms 
ALGOL, 4-1 

declaring global items in, 4-2 

example, 4-6, 4-7, 4-8, 5-10, 
5-18, 5-20, 5-26, 5-43 
binding process, description, 1-8 
C, 4-9 

example, 4-10 
COBOL, 4-11 

declaring global items in, 4-1 1 

declaring global items in 
(example), 4-11 

example, 4-14, 5-32, 5-43, 5-44 
definition, 1-1 
description, 1-3 
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subprograms (cont.) 

effect of BIND statement on, during 

binding, 1-7 
effect of EXTERNAL statement on, 

during binding, 1-7 
examples of, 1-4 
external, 1-3 

BIND statement for, 3-^3 
file 

titling of, 1-4 
FORTRAN, 4-15, 5-39 

example, 4-17, 5-11, 5-42 
FORTRAN77, 4-17,5-39 

example, 4-19, 5-21 
identifier 

examples, 2-5 
explanation, 2-5 
syntax, 2-5 
nesting structure, 2-6 
PL/I, 4-21 

example, 4-23 
processing by Binder, 1-7 
requirements when binding ALGOL and 

NEWP, 5-21 
restrictions when binding ALGOL and 

FORTRAN77, 5-13 
titling of, 1-4 
subroutines, titling, 5-40 
switch items, declaring in ALGOL 

binding, 4-2 
SYSTEM/PRINTBINDINFO utility 
description, 8-1 

T 

TASKVALUE task attribute, 

PRINTBINDINFO utility, 8-6 

TIME option in Binder control 
record, B-5 

title 

of a subprogram, 1-4 

u 

<underscore>, 2-2 
underscore character, use in file 

specifier, 2-2 
unresolved external references 

avoiding, 1-5 

causes of, 1-5 



unresolved external references (cont.) 

description, 1-5 
USE statement 

discussion, 3-10 

examples, 3-1 1 

for COMS library match between 
ALGOL and COBOL, 5-4 

purpose, 3-10 

syntax, 3-10 

use in equating ALGOL and Pascal 

identifiers, 5-24 
use in replacing a main program with a 
subroutine, 5-40 
USEHOSTSIZE option in Binder control 

record, B-5 
<usercode>, 2-2 
usercode 

use in file specifier, 2-2 

V 

values, initial, using with FORTRAN 

common blocks, 5-15 
variables 
ALGOL 

corresponding COBOL 

identifiers, 5-2 
corresponding FORTRAN 

identifiers, 5-5 
corresponding FORTRAN77 

identifiers, 5-12 
corresponding Pascal 
identifiers, 5-22 
declaring 

when binding C with C, 4-9 
FORTRAN 

corresponding COBOL 
identifiers, 5-27 
FORTRAN77 

corresponding COBOL 
identifiers, 5-29 
global 

sharing between ALGOL and 

COBOL, 5-3 
sharing between ALGOL and 

FORTRAN, 5-7 
sharing between ALGOL and 

FORTRAN77, 5-12 
sharing between ALGOL and 

Pascal, 5-24 
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variables (cont.) 
global (cont.) 

sharing between COBOL and 

FORTRAN, 5-28 
sharing between COBOL and 

FORTRAN??, 5-30 
sharing between COBOL and 
Pascal, 5-35 
STATIC EXTERNAL in PL/I, 4-22 

w 

WAIT option in Binder control 

record, B-6 
WARN option in Binder control 

record, B-6 
warning messages, A-1 
words 

reserved, 1-? 



Special Characters 

$ (dollar sign), use in Binder control 

record, B-1 
= (equal sign) 

use in BIND statement, 3-3 
use in file specifier, 2-2 
% (percent sign), use in Binder control 

record, 3-1, B-1 
? (question mark), use in BIND 

statement, 3-3 
; (semicolon), use in Binder records, 3-1 
/ (slash), use in common block 

declaration, 5-? 
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